From root@core3.amsl.com Fri Oct 2 07:30:02 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E740F3A6827; Fri, 2 Oct 2009 07:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091002143001.E740F3A6827@core3.amsl.com> Date: Fri, 2 Oct 2009 07:30:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-10.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 14:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks Author(s) : W. Sun, et al. Filename : draft-ietf-ccamp-lsp-dppm-10.txt Pages : 53 Date : 2009-10-02 Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. The dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can be used to characterize the features of GMPLS networks in LSP dynamic provisioning. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-lsp-dppm-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-02072646.I-D@ietf.org> --NextPart-- From lberger@labn.net Fri Oct 2 14:35:50 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F303A68D0 for ; Fri, 2 Oct 2009 14:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyYBiGGXJkav for ; Fri, 2 Oct 2009 14:35:50 -0700 (PDT) Received: from outbound-mail-307.bluehost.com (outbound-mail-307.bluehost.com [67.222.53.253]) by core3.amsl.com (Postfix) with SMTP id 2FE3B3A67EF for ; Fri, 2 Oct 2009 14:35:50 -0700 (PDT) Received: (qmail 1358 invoked by uid 0); 2 Oct 2009 21:30:39 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy6.bluehost.com with SMTP; 2 Oct 2009 21:30:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=KFiYomLIPI3n6pjK71QPHAn+j9Bvg8P6BoYtt4YWXJvLCFlKDlJJFi8ZYpoe48H6yVvpheKRngKnBwNyyekKGJSje3C7IsZ5c7W6NZEJpgWsI8EvdSGsan/GPbWj+fYC; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Mtpi2-0003jI-Vd; Fri, 02 Oct 2009 15:30:39 -0600 Message-ID: <4AC67108.2030403@labn.net> Date: Fri, 02 Oct 2009 17:30:48 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Adrian Farrel X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org, iesg-secretary@ietf.org Subject: [CCAMP] Please publish: draft-ietf-ccamp-lsp-dppm-10 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 21:35:50 -0000 Proto-write-up for: draft-ietf-ccamp-lsp-dppm-10.txt Intended status: Proposed Standard >(1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? Lou Berger is the Document Shepherd. He has reviewed the document and believe this version is ready for publication at the intended status. >(1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? The document has received adequate review and discussion. It has been revised to be consistent with WG opinion and other related activities in the IETF. It has also been reviewed by experts from the IPPM and BM WGs. >(1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization, or XML? No. A final inter-WG review was conducted as part of LC process. >(1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? No. > For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. No IPR disclosures were found. >(1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? Consensus appears to be good. >(1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarize the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) No threats. No discontent. >(1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/.) Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type, and URI type reviews? If the document > does not already indicate its intended status at the top of > the first page, please indicate the intended status here. Yes. There are 2 instances of too long lines in the document. These can be resolved in the next rev. >(1.h) Has the document split its references into normative and > informative? Yes. > Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? No. > If such normative references exist, what is the > strategy for their completion? N/A. > Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. No downward references. > >(1.i) Has the Document Shepherd verified that the document's IANA > Considerations section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process, has the Document > Shepherd conferred with the Responsible Area Director so that > the IESG can appoint the needed Expert during IESG Evaluation? This document makes no requests for IANA action. >(1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? Yes, no automated checks needed. >(1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up. Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > Relevant content can frequently be found in the abstract > and/or introduction of the document. If not, this may be > an indication that there are deficiencies in the abstract > or introduction. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can be used to characterize the LSP dynamic provisioning features of GMPLS networks. > Working Group Summary > Was there anything in the WG process that is worth noting? > For example, was there controversy about particular points > or were there decisions where the consensus was > particularly rough? This document received adequate attention and discussion. The discussions related to this document have also resulted in the companion draft for characterization of data plane setup metrics "Label Switched Path (LSP) Data Path Delay Metric in Generalized MPLS / MPLS-TE Networks". > Document Quality > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type, or other Expert Review, > what was its course (briefly)? In the case of a Media Type > Review, on what date was the request posted? > There have been no public statements related to intent to implement, but it is expected that some/all of the primary Authors plan to implement. > Personnel > Who is the Document Shepherd for this document? Lou Berger. > Who is the > Responsible Area Director? Adrian Farrel > If the document requires IANA > experts(s), insert 'The IANA Expert(s) for the registries > in this document are .' > From loa@pi.nu Sun Oct 4 22:38:50 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F69E3A6996; Sun, 4 Oct 2009 22:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FX2AmCLE4s9p; Sun, 4 Oct 2009 22:38:49 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 495D23A6995; Sun, 4 Oct 2009 22:38:49 -0700 (PDT) Received: from [192.168.12.236] (unknown [195.65.225.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 9134DD404F; Mon, 5 Oct 2009 07:40:21 +0200 (CEST) Message-ID: <4AC986C4.4040106@pi.nu> Date: Mon, 05 Oct 2009 07:40:20 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, "mpls-tp@ietf.org" , 'MPLS-TP ad hoc' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] Closing the IETF MEAD team X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 05:38:50 -0000 Dear all, The main MPLS-TP requirements work has been published as RFC 5654, and the two subsidiary requirements documents (NM and OAM) are close to publication with IETF last call ending later this week. The other key documents (the framework documents) have been adopted as MPLS working group documents and their text is substantially in place. Furthermore, a large number of the necessary solutions documents have been started and have good foundations. With this in mind, we think that the MEAD team has successfully delivered on its objectives. In view of the need to ensure that the MPLS-TP work is fully open to participation by everyone in the IETF community, and with the desire to "normalise" the process of document production and evolution, we have decided to close the MEAD team with immediate effect. All MPLS-TP work will now follow the usual IETF working group process with the MPLS working group being the lead working group, but with work being coordinated across other working groups (e.g. PWE3, CCAMP, Ops Area WG) as appropriate. We would like to take this opportunity to thank everyone who contributed to the work of the MEAD team, and hope that they will continue to participate in this effort within the IETF with the additional participation of all their colleagues. Best regards, Loa and Adrian -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From vishwas.ietf@gmail.com Tue Oct 6 11:49:40 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E105B3A68B8 for ; Tue, 6 Oct 2009 11:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.714 X-Spam-Level: X-Spam-Status: No, score=-0.714 tagged_above=-999 required=5 tests=[AWL=-1.681, BAYES_05=-1.11, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQIFMOepscNb for ; Tue, 6 Oct 2009 11:49:40 -0700 (PDT) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id 376DE3A66B4 for ; Tue, 6 Oct 2009 11:49:40 -0700 (PDT) Received: by yxe4 with SMTP id 4so4107071yxe.32 for ; Tue, 06 Oct 2009 11:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=VrYVk4bXsZoMo72iDhlPNXPXPKk8uoSr4x4raFAwELo=; b=qDJ3UmMJPEiiVrL7vtk85k8Xv31U9huY+AzVOvsSlonJRNdggfIZ+Je15KFSkcpj/U lTESrLxC3TYDqADaMAgYSbLgP2Co7193Eqlq75HlmxG4n/JIXU+9Zd7FmERuy0HuNCwS vo+lBsCMyEtz0AMBC7Y0yw0W3pdjfNEeEx/b0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Xu/af9wTbdgh8UZB1WK8QwBVFH5YLq/+Ukkwd86r8SEmbasxFZv+n+VZkZHtpP3scF FBa/erdTrSSgrmxu9ECVSI6gQWlVs9hFdW3SCDTwvlJ9DHY2hHtfTHXy44YTepdic05K JK+YoPtBNJwjQDC21BD7vq83Pdrr2yVHWpS0k= MIME-Version: 1.0 Received: by 10.150.16.2 with SMTP id 2mr2914648ybp.251.1254855075151; Tue, 06 Oct 2009 11:51:15 -0700 (PDT) Date: Tue, 6 Oct 2009 11:51:15 -0700 Message-ID: <77ead0ec0910061151y5c47445bg1c48fee5460ac892@mail.gmail.com> From: Vishwas Manral To: ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [CCAMP] LMP RFC4204 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 18:49:41 -0000 Hi, I am a bit confused about the statement below: "An LMP implementation SHOULD be able to fragment when transmitting LMP messages, and MUST be able to re-assemble IP fragments when receiving LMP messages." Does this mean that IP fragmentaion and reassembly will take care of the bigger then MTU messages, or does it mean LMP needs to do the same? If the latter how do we identify different messages which are part of the same message. Thanks, Vishwas From lberger@labn.net Tue Oct 6 12:05:07 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79C763A685B for ; Tue, 6 Oct 2009 12:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.043 X-Spam-Level: X-Spam-Status: No, score=-2.043 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCkrq3TeHyWv for ; Tue, 6 Oct 2009 12:05:06 -0700 (PDT) Received: from outbound-mail-314.bluehost.com (outbound-mail-314.bluehost.com [67.222.54.7]) by core3.amsl.com (Postfix) with SMTP id 8B09A3A684B for ; Tue, 6 Oct 2009 12:05:06 -0700 (PDT) Received: (qmail 12769 invoked by uid 0); 6 Oct 2009 19:06:44 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy6.bluehost.com with SMTP; 6 Oct 2009 19:06:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=sNK8nBqY2MkLp9IcpDlSZo+4wlhv3ytf+mmwbNeS56B6vJKkpQvsJnV7QkK0jYFkL52+yJoctbLHBxobpkcQt/IKy8vBsk6oz/EXB/LD2aWwHR+VFEK/52WyTADq/vPT; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MvFMy-0007eb-16; Tue, 06 Oct 2009 13:06:44 -0600 Message-ID: <4ACB955E.5010900@labn.net> Date: Tue, 06 Oct 2009 15:07:10 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Vishwas Manral References: <77ead0ec0910061151y5c47445bg1c48fee5460ac892@mail.gmail.com> In-Reply-To: <77ead0ec0910061151y5c47445bg1c48fee5460ac892@mail.gmail.com> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] LMP RFC4204 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 19:05:07 -0000 IMO fragment = "use IP fragmentation". I think this is clear from the context given the reassembly requirement. If it was LMP "semantic fragmentation", I'd expect a bit more discussion on the topic. Lou On 10/6/2009 2:51 PM, Vishwas Manral wrote: > Hi, > > I am a bit confused about the statement below: > > "An LMP implementation SHOULD be able to fragment when transmitting > LMP messages, and MUST be able to re-assemble IP fragments when > receiving LMP messages." > > Does this mean that IP fragmentaion and reassembly will take care of > the bigger then MTU messages, or does it mean LMP needs to do the > same? If the latter how do we identify different messages which are > part of the same message. > > Thanks, > Vishwas > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From vishwas.ietf@gmail.com Tue Oct 6 12:11:20 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA7428C20E for ; Tue, 6 Oct 2009 12:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6pezvGHUB3P for ; Tue, 6 Oct 2009 12:11:19 -0700 (PDT) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id 5575228C1FD for ; Tue, 6 Oct 2009 12:11:19 -0700 (PDT) Received: by yxe4 with SMTP id 4so4125836yxe.32 for ; Tue, 06 Oct 2009 12:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vAgaHJT4Iu07ok3a4oNsRNEpfzz+jayQWGSWn5EHl8I=; b=JM4xHgEMLLI6pPoDGzrfm7QShcN1Pxyh7mNLjIo2olUL2xnDuSogzeF4e+DoTA7+4l 81V04BTmGIt2ZwNGqPEM1JMOx5l/rXMNxyCnPTvL7sin1P2iBtau0wRLduO3bKkzV89o VRXbR3X7WbMC4apsvNB38KCfWlGbhbLPbz0f8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=plt9ZWzVFaqoTPLK/zvb8nDUTfubAtfiWFxL4hym/M9GJXV0UvrCHa9UXv9huX4Hjc lr+kvcRS5eLZH5ZdFrc/V2QjwuCjeygT8CfZd9XxsBcBRlglSlo/1pHGdK/+lw/zpMFj FuCrzi7TVM/zJ8uj0nhLiNp7ocAjYwI4eo8Vs= MIME-Version: 1.0 Received: by 10.150.16.2 with SMTP id 2mr2952223ybp.251.1254856372222; Tue, 06 Oct 2009 12:12:52 -0700 (PDT) In-Reply-To: <4ACB955E.5010900@labn.net> References: <77ead0ec0910061151y5c47445bg1c48fee5460ac892@mail.gmail.com> <4ACB955E.5010900@labn.net> Date: Tue, 6 Oct 2009 12:12:52 -0700 Message-ID: <77ead0ec0910061212t68f19f78m8fdb919c675fc119@mail.gmail.com> From: Vishwas Manral To: Lou Berger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ccamp@ietf.org Subject: Re: [CCAMP] LMP RFC4204 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 19:11:20 -0000 Hi Lou, Then in my perspective it is not the LMP doing the fragmentation, it is the IP doing the fragmentation. I am ok as long as we mean IP fragmentation and Reassembly!! Thanks for your quick reply, Vishwas On Tue, Oct 6, 2009 at 12:07 PM, Lou Berger wrote: > IMO fragment =3D "use IP fragmentation". =A0I think this is clear from th= e > context given the reassembly requirement. If it was LMP "semantic > fragmentation", I'd expect a bit more discussion on the topic. > > Lou > > On 10/6/2009 2:51 PM, Vishwas Manral wrote: >> Hi, >> >> I am a bit confused about the statement below: >> >> "An LMP implementation SHOULD be able to fragment when transmitting >> LMP messages, and MUST be able to re-assemble IP fragments when >> receiving LMP messages." >> >> Does this mean that IP fragmentaion and reassembly will take care of >> the bigger then MTU messages, or does it mean LMP needs to do the >> same? If the latter how do we identify different messages which are >> part of the same message. >> >> Thanks, >> Vishwas >> From vishwas.ietf@gmail.com Tue Oct 6 12:47:35 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC143A697B for ; Tue, 6 Oct 2009 12:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.416 X-Spam-Level: X-Spam-Status: No, score=-1.416 tagged_above=-999 required=5 tests=[AWL=-0.894, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgtXbIoQ6Cp2 for ; Tue, 6 Oct 2009 12:47:35 -0700 (PDT) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id D5CA43A68FF for ; Tue, 6 Oct 2009 12:47:34 -0700 (PDT) Received: by yxe4 with SMTP id 4so4157470yxe.32 for ; Tue, 06 Oct 2009 12:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Pv65brwdx78LHpP9/oaI9d+6wvYj2ffZ4ze1ehy+46o=; b=FwUsBpTqHZoolRvVhtJ8Z939htUbL9ToY9G0YR2DUr3T8h8NrsFaWLMWrpP1kV2K1m C+XyQMLKIxAQevVqam2cmHRO5gF1RsoOHTzUTMhssyeTL1yt75j7SlkkP50AeuRzDyRu SBqYrpT19mMzIuh7iOZPnnmgEMngxOG716QoI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=fS87kzwcMt2N4j8ImGUypMiA7IFQFkXYDHgw7MYzX+WTIKcqpMVR/WT9OX3lKFG6PB hlQjkNYjTMBK0bB3nglJQwlodrDXjpBcQFcyx9SmeivzqXp947EmrwGbTpTh3wavHnBw GlqoiR+ahLd654B5AXXX8hm6Bf2R+YXTT2LQ0= MIME-Version: 1.0 Received: by 10.151.93.20 with SMTP id v20mr3095958ybl.59.1254858550076; Tue, 06 Oct 2009 12:49:10 -0700 (PDT) Date: Tue, 6 Oct 2009 12:49:10 -0700 Message-ID: <77ead0ec0910061249s148c9baqedc734a705e9c985@mail.gmail.com> From: Vishwas Manral To: ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [CCAMP] LMP RFC4204 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 19:47:35 -0000 Hi, The Link Property Correlation (LPC) happens before the Link Connectivity verification (LCV) procedure. The LCV seems like a mechanisms by which we can learn the remote Interface_ID's. However the RFC states that: If the LinkSummary message is received from a remote node, and the Interface_Id mappings match those that are stored locally, then the two nodes have agreement on the Verification procedure (see Section 5) and data link identification configuration. What does it mean to be in agreement on the verification procedure? Does it mean only after LPC success we do not have to do the LCV (as property verification is already done)? It also states that: If the verification procedure is not used, the LinkSummary message can be used to verify agreement on manual configuration. So what configuration should not be verified when the Verification procedure is used? Thanks, Vishwas From giomarti@cisco.com Wed Oct 7 00:16:42 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F3428C266 for ; Wed, 7 Oct 2009 00:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=-3.983, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cn4RmKYDzttw for ; Wed, 7 Oct 2009 00:16:41 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C487028C25E for ; Wed, 7 Oct 2009 00:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=giomarti@cisco.com; l=1496; q=dns/txt; s=amsiport01001; t=1254899900; x=1256109500; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Giovanni=20Martinelli=20 |Subject:=20Re:=20[CCAMP]=20How=20to=20Specify=20Regenera tion=20at=20a=20particular=20node=20in=20RSVP-TE?|Date: =20Wed,=2007=20Oct=202009=2009:18:18=20+0200|Message-ID: =20<4ACC40BA.1030103@cisco.com>|To:=20Greg=20Bernstein=20 |CC:=20CCAMP=20|MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<4AAE7742.9090205@grotto-networking.com> |References:=20<4AAE7742.9090205@grotto-networking.com>; bh=qvs+iLryiUlTR6Rjv3OkRhr67xETO46hiJdcrC9kzYE=; b=kgbTUU3ToXRrMShP2eEyNJmpqMUqaJGEqnBBlos5XsaiGktFouBSKOZo 0f0gvzsmTzC2D5EDHeENr9LMNtR8FwZxOqLRQeDXhPBsJAA5xot3zhAzi +jFhLpDU+58wzqm0As1Krwsz1JYjegbRVWOKWsF8z+0nWr4nyc7DAfo1P g=; Authentication-Results: ams-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=giomarti@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8AAMLdy0qQ/uCKe2dsb2JhbACafAEBFiQGoGuIYwGPNQaEKg X-IronPort-AV: E=Sophos;i="4.44,518,1249257600"; d="scan'208";a="51143998" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Oct 2009 07:18:18 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n977IIJF021085; Wed, 7 Oct 2009 09:18:18 +0200 Received: from [144.254.172.213] (mnza1-dhcp-vl250-144-254-172-213.cisco.com [144.254.172.213]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n977IIMh010608; Wed, 7 Oct 2009 07:18:18 GMT Message-ID: <4ACC40BA.1030103@cisco.com> Date: Wed, 07 Oct 2009 09:18:18 +0200 From: Giovanni Martinelli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Greg Bernstein References: <4AAE7742.9090205@grotto-networking.com> In-Reply-To: <4AAE7742.9090205@grotto-networking.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1496; t=1254899898; x=1255763898; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=giomarti@cisco.com; z=From:=20Giovanni=20Martinelli=20 |Subject:=20Re=3A=20[CCAMP]=20How=20to=20Specify=20Regenera tion=20at=20a=20particular=20node=20in=20RSVP-TE? |Sender:=20; bh=qvs+iLryiUlTR6Rjv3OkRhr67xETO46hiJdcrC9kzYE=; b=Shhz/CFT8+o+Tf38r8mZvWaxCwNgAaH9dS7zNmjgaejQmPxxhH5RlqDUIL qz65BitNsRTDmt5jikz+BhcWuSwKF29MTzPdycwQPj5ysMSh39FHnKQ/pNjw sw6hbZujUG; Cc: CCAMP Subject: Re: [CCAMP] How to Specify Regeneration at a particular node in RSVP-TE? X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 07:16:42 -0000 Hi Greg, is this info required for any kind of RWA? Cheers G Greg Bernstein wrote: > Hi folks, we are continuing to investigate the generalization of the > WSON work to include regenerators, OEOs and the like. > We have a question to how to best indicate via RSVP-TE that a > particular processing operation such as regeneration is to take place at > a particular node along the path. > > Previous GMPLS work supports the signaling of wavelength conversion at > a particular node along the path since the Explicit Route Object (ERO) > supports a label sub-object and one can use a fixed mapping such as > [Otani] between labels and wavelengths. > > If we want to specify other types of processing at a particular node > along the path should we define new ERO sub-objects? > Another approach seems to be that of RFC5420 concerning LSP > attributes. In particular RFC5420 states: > 10.2. Communicating to Key Transit LSRs > Processing for key transit LSRs (such as ABRs and ASBRs) follows > exactly as for egress LSR. The only difference is that the > definition of the LSP attribute in the defining RFC will state that > the attribute must be acted on by these transit LSRs. > Now to use this, it seems that we'd need to include the IP address of > the node we want to perform the processing in the TLV, which seems > kind of redundant with what we already have in the ERO... > > Comments, questions, other alternatives? > > Cheers > > Greg B. > From Jonathan.Sadler@tellabs.com Wed Oct 7 00:43:31 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BBB93A6986 for ; Wed, 7 Oct 2009 00:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMDP9rvpqr-Y for ; Wed, 7 Oct 2009 00:43:30 -0700 (PDT) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id 91AD03A69A0 for ; Wed, 7 Oct 2009 00:43:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,518,1249257600"; d="scan'208";a="1298137805" Received: from usnvwwmspht01.hq.tellabs.com (HELO usnvwwmspht01.tellabs-west.tellabsinc.net) ([172.23.211.69]) by mx4-priv.tellabs.com with ESMTP; 07 Oct 2009 07:42:01 +0000 Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwmspht01.tellabs-west.tellabsinc.net ([172.23.211.69]) with mapi; Wed, 7 Oct 2009 02:42:01 -0500 From: "Sadler, Jonathan B." To: Greg Bernstein , CCAMP Date: Wed, 7 Oct 2009 02:42:04 -0500 Thread-Topic: [CCAMP] How to Specify Regeneration at a particular node in RSVP-TE? Thread-Index: Aco1XU4x2VvOURWAQnCqF7mE5H8YBARw4f2Q Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2B5DE5B18324@EX-NAP.tellabs-west.tellabsinc.net> References: <4AAE7742.9090205@grotto-networking.com> In-Reply-To: <4AAE7742.9090205@grotto-networking.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] How to Specify Regeneration at a particular node in RSVP-TE? X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 07:43:31 -0000 Hi Greg, Since Regeneration requires termination of the E-M wave which inherently wi= ll cause destruction of CI in order to get at the AI*, regeneration is a mu= lti-layer interaction. I would suggest that the EROs would have the ports = associated with the server-to-client layer transition in them (on both the = ingress to the regenerator and the egress from the regenerator) to indicate= invocation of a regenerator.=20 Jonathan Sadler * One such CI characteristic of the E-M wave that is lost is photon state. = This is e.g. why regeneration cannot be performed in the middle of a path = used for passing cryptographic information in a quantum-key encryption syst= em. -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of G= reg Bernstein Sent: Monday, September 14, 2009 12:03 PM To: CCAMP Subject: [CCAMP] How to Specify Regeneration at a particular node in RSVP-T= E? Hi folks, we are continuing to investigate the generalization of the=20 WSON work to include regenerators, OEOs and the like. We have a question to how to best indicate via RSVP-TE that a particular=20 processing operation such as regeneration is to take place at a particular node along the path. Previous GMPLS work supports the signaling of wavelength conversion at a=20 particular node along the path since the Explicit Route Object (ERO)=20 supports a label sub-object and one can use a fixed mapping such as=20 [Otani] between labels and wavelengths. If we want to specify other types of processing at a particular node=20 along the path should we define new ERO sub-objects? Another approach seems to be that of RFC5420 concerning LSP attributes.=20 In particular RFC5420 states: 10.2. Communicating to Key Transit LSRs Processing for key transit LSRs (such as ABRs and=20 ASBRs) follows exactly as for egress LSR. The only difference is=20 that the definition of the LSP attribute in the defining RFC=20 will state that the attribute must be acted on by these transit LSRs. Now to use this, it seems that we'd need to include the IP address of=20 the node we want to perform the processing in the TLV, which seems kind=20 of redundant with what we already have in the ERO... Comments, questions, other alternatives? Cheers Greg B. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From gregb@grotto-networking.com Wed Oct 7 07:41:30 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B289B3A691C for ; Wed, 7 Oct 2009 07:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckJcrO-muTrk for ; Wed, 7 Oct 2009 07:41:28 -0700 (PDT) Received: from mail30c40.carrierzone.com (mail30c40.carrierzone.com [209.235.156.170]) by core3.amsl.com (Postfix) with ESMTP id 52BB33A6AA8 for ; Wed, 7 Oct 2009 07:41:28 -0700 (PDT) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by mail30c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id n97EgtRY013705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Oct 2009 14:42:59 GMT Message-ID: <4ACCA8F4.5090802@grotto-networking.com> Date: Wed, 07 Oct 2009 07:43:00 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Giovanni Martinelli References: <4AAE7742.9090205@grotto-networking.com> <4ACC40BA.1030103@cisco.com> In-Reply-To: <4ACC40BA.1030103@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CCAMP Subject: Re: [CCAMP] How to Specify Regeneration at a particular node in RSVP-TE? X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 14:41:31 -0000 Hi Giovanni, this information is not needed for the type of RWA for the WSONs covered in the RWA Framework, RWA Info, or RWA encoding working group drafts. It is needed in some network situations covered in the "WSON compatibility" individual draft and the "WSON Impairments" working group draft. We'll be updating the "WSON compatibility" draft next week to be explicit as to exactly what extensions are needed in a particular networking context. This should have no impact on moving the Framework, Info, and Encoding drafts towards last call. Cheers Greg Giovanni Martinelli wrote: > Hi Greg, > > is this info required for any kind of RWA? > > Cheers > G > > Greg Bernstein wrote: >> Hi folks, we are continuing to investigate the generalization of the >> WSON work to include regenerators, OEOs and the like. >> We have a question to how to best indicate via RSVP-TE that a >> particular processing operation such as regeneration is to take place at >> a particular node along the path. >> >> Previous GMPLS work supports the signaling of wavelength conversion >> at a particular node along the path since the Explicit Route Object >> (ERO) supports a label sub-object and one can use a fixed mapping >> such as [Otani] between labels and wavelengths. >> >> If we want to specify other types of processing at a particular node >> along the path should we define new ERO sub-objects? >> Another approach seems to be that of RFC5420 concerning LSP >> attributes. In particular RFC5420 states: >> 10.2. Communicating to Key Transit LSRs >> Processing for key transit LSRs (such as ABRs and ASBRs) follows >> exactly as for egress LSR. The only difference is that the >> definition of the LSP attribute in the defining RFC will state that >> the attribute must be acted on by these transit LSRs. >> Now to use this, it seems that we'd need to include the IP address of >> the node we want to perform the processing in the TLV, which seems >> kind of redundant with what we already have in the ERO... >> >> Comments, questions, other alternatives? >> >> Cheers >> >> Greg B. >> > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From gregb@grotto-networking.com Wed Oct 7 07:45:17 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8983C28C15F for ; Wed, 7 Oct 2009 07:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Pv34itVMIbE for ; Wed, 7 Oct 2009 07:45:16 -0700 (PDT) Received: from mail16c40.carrierzone.com (mail16c40.carrierzone.com [209.235.156.156]) by core3.amsl.com (Postfix) with ESMTP id 82CC628C1AB for ; Wed, 7 Oct 2009 07:45:15 -0700 (PDT) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by mail16c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id n97EksGh017319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Oct 2009 14:46:58 GMT Message-ID: <4ACCA9DA.8020407@grotto-networking.com> Date: Wed, 07 Oct 2009 07:46:50 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Sadler, Jonathan B." References: <4AAE7742.9090205@grotto-networking.com> <5292FFA96EC22A4386067E9DBCC0CD2B5DE5B18324@EX-NAP.tellabs-west.tellabsinc.net> In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2B5DE5B18324@EX-NAP.tellabs-west.tellabsinc.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CCAMP Subject: Re: [CCAMP] How to Specify Regeneration at a particular node in RSVP-TE? X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 14:45:17 -0000 CI? AI? Is the quantum state of a photon preserved though an optical amplifier? Maybe we need a separate draft on quantum communications and encryption and GMPLS. Greg Sadler, Jonathan B. wrote: > Hi Greg, > > Since Regeneration requires termination of the E-M wave which inherently will cause destruction of CI in order to get at the AI*, regeneration is a multi-layer interaction. I would suggest that the EROs would have the ports associated with the server-to-client layer transition in them (on both the ingress to the regenerator and the egress from the regenerator) to indicate invocation of a regenerator. > > Jonathan Sadler > > * One such CI characteristic of the E-M wave that is lost is photon state. This is e.g. why regeneration cannot be performed in the middle of a path used for passing cryptographic information in a quantum-key encryption system. > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein > Sent: Monday, September 14, 2009 12:03 PM > To: CCAMP > Subject: [CCAMP] How to Specify Regeneration at a particular node in RSVP-TE? > > Hi folks, we are continuing to investigate the generalization of the > WSON work to include regenerators, OEOs and the like. > We have a question to how to best indicate via RSVP-TE that a particular > processing operation such as regeneration is to take place at > a particular node along the path. > > Previous GMPLS work supports the signaling of wavelength conversion at a > particular node along the path since the Explicit Route Object (ERO) > supports a label sub-object and one can use a fixed mapping such as > [Otani] between labels and wavelengths. > > If we want to specify other types of processing at a particular node > along the path should we define new ERO sub-objects? > Another approach seems to be that of RFC5420 concerning LSP attributes. > In particular RFC5420 states: > 10.2. Communicating to Key Transit LSRs > Processing for key transit LSRs (such as ABRs and > ASBRs) follows > exactly as for egress LSR. The only difference is > that the > definition of the LSP attribute in the defining RFC > will state that > the attribute must be acted on by these transit LSRs. > Now to use this, it seems that we'd need to include the IP address of > the node we want to perform the processing in the TLV, which seems kind > of redundant with what we already have in the ERO... > > Comments, questions, other alternatives? > > Cheers > > Greg B. > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From zhangfatai@huawei.com Wed Oct 7 08:21:49 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A4828C18B for ; Wed, 7 Oct 2009 08:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+z6CUWMhHPx for ; Wed, 7 Oct 2009 08:21:48 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 1089D28C1B6 for ; Wed, 7 Oct 2009 08:21:48 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KR5004NTHF31Y@usaga01-in.huawei.com> for ccamp@ietf.org; Wed, 07 Oct 2009 08:23:27 -0700 (PDT) Received: from zhang ([156.106.219.50]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KR5001FPHF15J@usaga01-in.huawei.com> for ccamp@ietf.org; Wed, 07 Oct 2009 08:23:27 -0700 (PDT) Date: Wed, 07 Oct 2009 23:23:23 +0800 From: Fatai Zhang To: Greg Bernstein , "Sadler, Jonathan B." Message-id: <004301ca4762$1d22fdc0$32db6a9c@zhang> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4AAE7742.9090205@grotto-networking.com> <5292FFA96EC22A4386067E9DBCC0CD2B5DE5B18324@EX-NAP.tellabs-west.tellabsinc.net> <4ACCA9DA.8020407@grotto-networking.com> Cc: CCAMP Subject: Re: [CCAMP] How to Specify Regeneration at a particular node inRSVP-TE? X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 15:21:49 -0000 Hi, Greg and Jonathan, I think the possible approaches mentioned by Greg are simple and useful to resolve the issues. It will make things complex if we use EROs to indicate the ports association between server and client layer, because how to regenerate the signals is the local matter of the node. Fatai ----- Original Message ----- From: "Greg Bernstein" To: "Sadler, Jonathan B." Cc: "CCAMP" Sent: Wednesday, October 07, 2009 10:46 PM Subject: Re: [CCAMP] How to Specify Regeneration at a particular node inRSVP-TE? > CI? AI? Is the quantum state of a photon preserved though an optical > amplifier? Maybe we need a separate draft on quantum communications and > encryption and GMPLS. > > Greg > > Sadler, Jonathan B. wrote: >> Hi Greg, >> >> Since Regeneration requires termination of the E-M wave which inherently will cause destruction of CI in order to get at the AI*, regeneration is a multi-layer interaction. I would suggest that the EROs would have the ports associated with the server-to-client layer transition in them (on both the ingress to the regenerator and the egress from the regenerator) to indicate invocation of a regenerator. >> >> Jonathan Sadler >> >> * One such CI characteristic of the E-M wave that is lost is photon state. This is e.g. why regeneration cannot be performed in the middle of a path used for passing cryptographic information in a quantum-key encryption system. >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein >> Sent: Monday, September 14, 2009 12:03 PM >> To: CCAMP >> Subject: [CCAMP] How to Specify Regeneration at a particular node in RSVP-TE? >> >> Hi folks, we are continuing to investigate the generalization of the >> WSON work to include regenerators, OEOs and the like. >> We have a question to how to best indicate via RSVP-TE that a particular >> processing operation such as regeneration is to take place at >> a particular node along the path. >> >> Previous GMPLS work supports the signaling of wavelength conversion at a >> particular node along the path since the Explicit Route Object (ERO) >> supports a label sub-object and one can use a fixed mapping such as >> [Otani] between labels and wavelengths. >> >> If we want to specify other types of processing at a particular node >> along the path should we define new ERO sub-objects? >> Another approach seems to be that of RFC5420 concerning LSP attributes. >> In particular RFC5420 states: >> 10.2. Communicating to Key Transit LSRs >> Processing for key transit LSRs (such as ABRs and >> ASBRs) follows >> exactly as for egress LSR. The only difference is >> that the >> definition of the LSP attribute in the defining RFC >> will state that >> the attribute must be acted on by these transit LSRs. >> Now to use this, it seems that we'd need to include the IP address of >> the node we want to perform the processing in the TLV, which seems kind >> of redundant with what we already have in the ERO... >> >> Comments, questions, other alternatives? >> >> Cheers >> >> Greg B. >> >> > > -- > =================================================== > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From Lyong@Ciena.com Wed Oct 7 08:38:36 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17CB628C1AC for ; Wed, 7 Oct 2009 08:38:36 -0700 (PDT) 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_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7yMqaG6gXOq for ; Wed, 7 Oct 2009 08:38:35 -0700 (PDT) Received: from hicks.ciena.com (hicks.ciena.com [63.118.34.22]) by core3.amsl.com (Postfix) with ESMTP id 09FC028C0F8 for ; Wed, 7 Oct 2009 08:38:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALxSzEo/dicV/2dsb2JhbADIPwmPDYJKgWAE X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Oct 2009 11:40:08 -0400 Message-ID: <0AFD1B67B949784DA087CDA9F0DD4AD9010B1F1E@mdmxm03.ciena.com> In-Reply-To: <4ACCA9DA.8020407@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] How to Specify Regeneration at a particular node inRSVP-TE? Thread-Index: AcpHXTiG8q7SKVdCT3OaOgd6t52x7QABwo+g References: <4AAE7742.9090205@grotto-networking.com><5292FFA96EC22A4386067E9DBCC0CD2B5DE5B18324@EX-NAP.tellabs-west.tellabsinc.net> <4ACCA9DA.8020407@grotto-networking.com> From: "Ong, Lyndon" Importance: normal Priority: normal To: "Greg Bernstein" , "Sadler, Jonathan B." Cc: CCAMP Subject: Re: [CCAMP] How to Specify Regeneration at a particular node inRSVP-TE? X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 15:38:36 -0000 CI=3DCharacteristic Information, AI=3DAdapted Information Can't help with quantum state and optical amplifiers, though. Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein Sent: Wednesday, October 07, 2009 7:47 AM To: Sadler, Jonathan B. Cc: CCAMP Subject: Re: [CCAMP] How to Specify Regeneration at a particular node inRSVP-TE? CI? AI? Is the quantum state of a photon preserved though an optical=20 amplifier? Maybe we need a separate draft on quantum communications and=20 encryption and GMPLS. Greg Sadler, Jonathan B. wrote: > Hi Greg, > > Since Regeneration requires termination of the E-M wave which inherently will cause destruction of CI in order to get at the AI*, regeneration is a multi-layer interaction. I would suggest that the EROs would have the ports associated with the server-to-client layer transition in them (on both the ingress to the regenerator and the egress from the regenerator) to indicate invocation of a regenerator.=20 > > Jonathan Sadler > > * One such CI characteristic of the E-M wave that is lost is photon state. This is e.g. why regeneration cannot be performed in the middle of a path used for passing cryptographic information in a quantum-key encryption system. > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein > Sent: Monday, September 14, 2009 12:03 PM > To: CCAMP > Subject: [CCAMP] How to Specify Regeneration at a particular node in RSVP-TE? > > Hi folks, we are continuing to investigate the generalization of the=20 > WSON work to include regenerators, OEOs and the like. > We have a question to how to best indicate via RSVP-TE that a particular=20 > processing operation such as regeneration is to take place at > a particular node along the path. > > Previous GMPLS work supports the signaling of wavelength conversion at a=20 > particular node along the path since the Explicit Route Object (ERO)=20 > supports a label sub-object and one can use a fixed mapping such as=20 > [Otani] between labels and wavelengths. > > If we want to specify other types of processing at a particular node=20 > along the path should we define new ERO sub-objects? > Another approach seems to be that of RFC5420 concerning LSP attributes.=20 > In particular RFC5420 states: > 10.2. Communicating to Key Transit LSRs > Processing for key transit LSRs (such as ABRs and=20 > ASBRs) follows > exactly as for egress LSR. The only difference is=20 > that the > definition of the LSP attribute in the defining RFC > will state that > the attribute must be acted on by these transit LSRs. > Now to use this, it seems that we'd need to include the IP address of=20 > the node we want to perform the processing in the TLV, which seems kind=20 > of redundant with what we already have in the ERO... > > Comments, questions, other alternatives? > > Cheers > > Greg B. > > =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From ylee@huawei.com Wed Oct 7 13:42:27 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980F83A693D for ; Wed, 7 Oct 2009 13:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.13 X-Spam-Level: X-Spam-Status: No, score=-2.13 tagged_above=-999 required=5 tests=[AWL=0.469, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtJMyKQu52XJ for ; Wed, 7 Oct 2009 13:42:26 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 681113A68AB for ; Wed, 7 Oct 2009 13:42:26 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KR5001H8W9IWK@usaga04-in.huawei.com> for ccamp@ietf.org; Wed, 07 Oct 2009 15:44:06 -0500 (CDT) Received: from L73682 ([10.124.12.76]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KR50082EW9DCB@usaga04-in.huawei.com> for ccamp@ietf.org; Wed, 07 Oct 2009 15:44:06 -0500 (CDT) Date: Wed, 07 Oct 2009 15:44:01 -0500 From: Young Lee In-reply-to: <4ACCA8F4.5090802@grotto-networking.com> To: ccamp@ietf.org Message-id: <004a01ca478e$e734b640$4c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpHXJ4wtMwEHZEpRyCP5T9QpPKjuwAMYehw References: <4AAE7742.9090205@grotto-networking.com> <4ACC40BA.1030103@cisco.com> <4ACCA8F4.5090802@grotto-networking.com> Subject: Re: [CCAMP] How to Specify Regeneration at a particular node inRSVP-TE? X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 20:42:27 -0000 Hi CCAMPers, We have updated WSON Signal Compatibility draft: http://www.ietf.org/id/draft-bernstein-ccamp-wson-compatibility-01.txt We presented the 00 version in the 75th IETF at Stockholm. As the WG chairs suggested, we have separated "Signal Compatibility" from WSON RWA work. Forward below is an I-D announcement. Appreciate your comment and suggestion. Thanks. Greg and Young -------------------------------------------------------------------------- A new version of I-D, draft-bernstein-ccamp-wson-compatibility-01.txt has been successfuly submitted by Young Lee and posted to the IETF repository. Filename: draft-bernstein-ccamp-wson-compatibility Revision: 01 Title: WSON Signal Characteristics and Network Element Compatibility Constraints for GMPLS Creation_date: 2009-10-07 WG ID: Independent Submission Number_of_pages: 21 Abstract: While the current GMPLS WSON framework can deal with many types of wavelength switching systems there is a desire to extend the control plane to networks that include a combination of transparent optical and hybrid electro optical systems such as OEO switches, regenerators, and wavelength converters. Such networks are frequently referred to as translucent optical networks in the literature. Some of the systems use in such networks can be limited to processing WSON signals with specific characteristics or attributes. In addition, some of the network elements may be able to perform important optional processing functions such as regeneration on a signal and would need to be provisioned as part of optical path establishment. This document provides a WSON signal definition and attributes characterization based on ITU-T interface and signal class standards and describes the signal compatibility constraints of this extended set of network elements. The signal characterization, network element compatibility constraints and enhanced provisioning support enable GMPLS routing and signaling to control these devices and PCE to compute optical light-paths subject to signal compatibility attributes. -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein Sent: Wednesday, October 07, 2009 9:43 AM To: Giovanni Martinelli Cc: CCAMP Subject: Re: [CCAMP] How to Specify Regeneration at a particular node inRSVP-TE? Hi Giovanni, this information is not needed for the type of RWA for the WSONs covered in the RWA Framework, RWA Info, or RWA encoding working group drafts. It is needed in some network situations covered in the "WSON compatibility" individual draft and the "WSON Impairments" working group draft. We'll be updating the "WSON compatibility" draft next week to be explicit as to exactly what extensions are needed in a particular networking context. This should have no impact on moving the Framework, Info, and Encoding drafts towards last call. Cheers Greg Giovanni Martinelli wrote: > Hi Greg, > > is this info required for any kind of RWA? > > Cheers > G > > Greg Bernstein wrote: >> Hi folks, we are continuing to investigate the generalization of the >> WSON work to include regenerators, OEOs and the like. >> We have a question to how to best indicate via RSVP-TE that a >> particular processing operation such as regeneration is to take place at >> a particular node along the path. >> >> Previous GMPLS work supports the signaling of wavelength conversion >> at a particular node along the path since the Explicit Route Object >> (ERO) supports a label sub-object and one can use a fixed mapping >> such as [Otani] between labels and wavelengths. >> >> If we want to specify other types of processing at a particular node >> along the path should we define new ERO sub-objects? >> Another approach seems to be that of RFC5420 concerning LSP >> attributes. In particular RFC5420 states: >> 10.2. Communicating to Key Transit LSRs >> Processing for key transit LSRs (such as ABRs and ASBRs) follows >> exactly as for egress LSR. The only difference is that the >> definition of the LSP attribute in the defining RFC will state that >> the attribute must be acted on by these transit LSRs. >> Now to use this, it seems that we'd need to include the IP address of >> the node we want to perform the processing in the TLV, which seems >> kind of redundant with what we already have in the ERO... >> >> Comments, questions, other alternatives? >> >> Cheers >> >> Greg B. >> > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From root@core3.amsl.com Thu Oct 8 13:30:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E5D293A68DD; Thu, 8 Oct 2009 13:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091008203001.E5D293A68DD@core3.amsl.com> Date: Thu, 8 Oct 2009 13:30:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-wson-encode-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 20:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks Author(s) : G. Bernstein Filename : draft-ietf-ccamp-rwa-wson-encode-03.txt Pages : 36 Date : 2009-10-08 A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. The information may be used in Generalized Multiprotocol Label Switching (GMPLS) signaling protocols, and may be distributed by GMPLS routing protocols. Other distribution mechanisms (for example, XML-based protocols) may also be used. This document provides efficient, protocol-agnostic encodings for the information elements necessary to operate a WSON. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-encode-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rwa-wson-encode-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-08132255.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Oct 9 10:45:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 993723A679F; Fri, 9 Oct 2009 10:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091009174501.993723A679F@core3.amsl.com> Date: Fri, 9 Oct 2009 10:45:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-info-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 17:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks Author(s) : G. Bernstein Filename : draft-ietf-ccamp-rwa-info-05.txt Pages : 18 Date : 2009-10-09 This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs, particularly in cases where there are no or a limited number of wavelength converters available. This model does not include optical impairments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rwa-info-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-09104144.I-D@ietf.org> --NextPart-- From gregb@grotto-networking.com Fri Oct 9 11:00:44 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 307E028C22B for ; Fri, 9 Oct 2009 11:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.072 X-Spam-Level: X-Spam-Status: No, score=-1.072 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxwrbyN-Vy81 for ; Fri, 9 Oct 2009 11:00:43 -0700 (PDT) Received: from mail16c40.carrierzone.com (mail16c40.carrierzone.com [209.235.156.156]) by core3.amsl.com (Postfix) with ESMTP id E652228C22A for ; Fri, 9 Oct 2009 11:00:42 -0700 (PDT) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by mail16c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id n99I2RwP000431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Oct 2009 18:02:33 GMT Message-ID: <4ACF7AAE.4000307@grotto-networking.com> Date: Fri, 09 Oct 2009 11:02:22 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: CCAMP Content-Type: multipart/alternative; boundary="------------080103070908020403090200" Subject: [CCAMP] WSON drafts ready for last call... X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 18:00:44 -0000 This is a multi-part message in MIME format. --------------080103070908020403090200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi CCAMP folks interested in WSON. Thanks for your inputs so far the three fundamental WSON drafts: (a) draft-ietf-ccamp-rwa-wson-framework-03.txt (b) draft-ietf-ccamp-rwa-info-05.txt (c) draft-ietf-ccamp-rwa-wson-encode-03.txt We'd like to last call these soon. So Deborah and Lou will need to let us know the procedures. For those that want to add editorial suggestions and fixes the MS Word versions are available at http://www.grotto-networking.com/wsonOutline and just follow the menu to the particular page related to the draft and all the files can be downloaded. Please turn change tracking on so we can see your suggestions. Best Regards Greg -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------080103070908020403090200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi CCAMP folks interested in WSON.  Thanks for your inputs so far the three fundamental WSON drafts:
    (a) draft-ietf-ccamp-rwa-wson-framework-03.txt
    (b) draft-ietf-ccamp-rwa-info-05.txt
    (c) draft-ietf-ccamp-rwa-wson-encode-03.txt

We'd like to last call these soon. So Deborah and Lou will need to let us know the procedures.
For those that want to add editorial suggestions and fixes the MS Word versions are available at
http://www.grotto-networking.com/wsonOutline and just follow the menu to the particular page related to the
draft and all the files can be downloaded. Please turn change tracking on so we can see your suggestions.

Best Regards

Greg

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------080103070908020403090200-- From root@core3.amsl.com Fri Oct 9 16:00:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 910203A6835; Fri, 9 Oct 2009 16:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091009230001.910203A6835@core3.amsl.com> Date: Fri, 9 Oct 2009 16:00:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-wson-framework-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 23:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-rwa-wson-framework-04.txt Pages : 46 Date : 2009-10-09 This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation architectures that could be realized via various combinations of extended GMPLS and PCE protocols. This memo focuses on topological elements and path selection constraints that are common across different WSON environments as such it does not address optical impairments in any depth nor does it address potential incompatibilities between some types of optical signals and some types of network elements and links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rwa-wson-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-09154658.I-D@ietf.org> --NextPart-- From gnewsome@ieee.org Sat Oct 10 09:41:34 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D81EC3A68E0 for ; Sat, 10 Oct 2009 09:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrBqvRbYz5Q4 for ; Sat, 10 Oct 2009 09:41:32 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 3BFF43A689E for ; Sat, 10 Oct 2009 09:41:32 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 07BA172AEB; Sat, 10 Oct 2009 12:43:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=kg/UiV2Xo2aa n0zmqNvlUV6CgY0=; b=lHk4i9kGWLrgUFh6Xan+0DW2BwPJwZ7wYOdB6cKR5JWh NMMWXaghEr2fdTlhPAmVebx8eUUN4m52CFCc4LlYz19FPj2vapgBdee7a32zr7w0 m+xBu4aTRmS6cvdWPA3jEFZ3TUzcEo08+oJCDxLWcZnYr7Ak9mGKs+q+Bww6VkI= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id DA36472AEA; Sat, 10 Oct 2009 12:43:15 -0400 (EDT) Received: from [192.168.123.102] (unknown [81.96.172.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 9F39372AE9; Sat, 10 Oct 2009 12:43:12 -0400 (EDT) Message-ID: <4AD0B99F.5060207@ieee.org> Date: Sat, 10 Oct 2009 12:43:11 -0400 From: George Newsome User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Fatai Zhang , Greg Bernstein References: <4AAE7742.9090205@grotto-networking.com> <5292FFA96EC22A4386067E9DBCC0CD2B5DE5B18324@EX-NAP.tellabs-west.tellabsinc.net> <4ACCA9DA.8020407@grotto-networking.com> <004301ca4762$1d22fdc0$32db6a9c@zhang> In-Reply-To: <004301ca4762$1d22fdc0$32db6a9c@zhang> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 01EA666A-B5BC-11DE-A98D-1000076EA04E-03525878!a-pb-sasl-sd.pobox.com Cc: CCAMP Subject: Re: [CCAMP] How to Specify Regeneration at a particular node X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Oct 2009 16:41:35 -0000 Fatai Zhang wrote: > Hi, Greg and Jonathan, > > I think the possible approaches mentioned by Greg are simple and > useful to resolve the issues. It will make things complex if we use > EROs to indicate the ports association between server and client > layer, because how to regenerate the signals is the local matter of > the node. > Hi Greg, Fatai, The regen situation is the same as or slightly different from the wavelength conversion problem depending on your assumptions. If you assume that the optical part of your network ONLY carries ODU's, then you can treat an ODU regenerator as if it is just another sublayer of an ODU. This is more or less the same as treating the wavelength as a sublayer of an OCh. However, if you want to allow for several different digital clients on the optical network, then you MUST make clear which layer provides the regenerator, and the simple sublayer model will not work. (You cannot apply an SDH or Ethernet signal to an ODU regen). I think this is a case of the more you can assume, the less you need to pass around. Or, corollary, the more variation, the more you need to tell other participants. So how regeneration is provided is NOT a local matter, but whether you need to signal it depends on the amount of variation in digital clients that you are trying to support. I think that allowing for more variation and having a parameter too many is preferable to making a wrong assumption and having a parameter too few. Regards, George > Fatai > > ----- Original Message ----- From: "Greg Bernstein" > To: "Sadler, Jonathan B." > Cc: "CCAMP" Sent: > Wednesday, October 07, 2009 10:46 PM Subject: Re: [CCAMP] How to > Specify Regeneration at a particular node inRSVP-TE? > > >> CI? AI? Is the quantum state of a photon preserved though an >> optical amplifier? Maybe we need a separate draft on quantum >> communications and encryption and GMPLS. >> >> Greg >> >> Sadler, Jonathan B. wrote: >>> Hi Greg, >>> >>> Since Regeneration requires termination of the E-M wave which >>> inherently will cause destruction of CI in order to get at the >>> AI*, regeneration is a multi-layer interaction. I would suggest >>> that the EROs would have the ports associated with the >>> server-to-client layer transition in them (on both the ingress to >>> the regenerator and the egress from the regenerator) to indicate >>> invocation of a regenerator. >>> >>> Jonathan Sadler >>> >>> * One such CI characteristic of the E-M wave that is lost is >>> photon state. This is e.g. why regeneration cannot be performed >>> in the middle of a path used for passing cryptographic >>> information in a quantum-key encryption system. >>> >>> -----Original Message----- From: ccamp-bounces@ietf.org >>> [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein Sent: >>> Monday, September 14, 2009 12:03 PM To: CCAMP Subject: [CCAMP] >>> How to Specify Regeneration at a particular node in RSVP-TE? >>> >>> Hi folks, we are continuing to investigate the generalization of >>> the WSON work to include regenerators, OEOs and the like. We have >>> a question to how to best indicate via RSVP-TE that a particular >>> processing operation such as regeneration is to take place at a >>> particular node along the path. >>> >>> Previous GMPLS work supports the signaling of wavelength >>> conversion at a particular node along the path since the Explicit >>> Route Object (ERO) supports a label sub-object and one can use a >>> fixed mapping such as [Otani] between labels and wavelengths. >>> >>> If we want to specify other types of processing at a particular >>> node along the path should we define new ERO sub-objects? Another >>> approach seems to be that of RFC5420 concerning LSP attributes. >>> In particular RFC5420 states: 10.2. Communicating to Key Transit >>> LSRs Processing for key transit LSRs (such as ABRs and ASBRs) >>> follows exactly as for egress LSR. The only difference is that >>> the definition of the LSP attribute in the defining RFC will >>> state that the attribute must be acted on by these transit LSRs. >>> Now to use this, it seems that we'd need to include the IP >>> address of the node we want to perform the processing in the TLV, >>> which seems kind of redundant with what we already have in the >>> ERO... >>> >>> Comments, questions, other alternatives? >>> >>> Cheers >>> >>> Greg B. >>> >>> >> -- =================================================== Dr Greg >> Bernstein, Grotto Networking (510) 573-2237 >> >> >> _______________________________________________ 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 giomarti@cisco.com Mon Oct 12 03:15:48 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36D928C191 for ; Mon, 12 Oct 2009 03:15:48 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hORbTc3xLDYZ for ; Mon, 12 Oct 2009 03:15:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 994EA28C184 for ; Mon, 12 Oct 2009 03:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=giomarti@cisco.com; l=2500; q=dns/txt; s=amsiport01001; t=1255342548; x=1256552148; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Giovanni=20Martinelli=20 |Subject:=20Re:=20[CCAMP]=20How=20to=20Specify=20Regenera tion=20at=20a=20particular=20node=20in=20RSVP-TE?|Date: =20Mon,=2012=20Oct=202009=2012:15:32=20+0200|Message-ID: =20<4AD301C4.4010808@cisco.com>|To:=20Greg=20Bernstein=20 |CC:=20CCAMP=20|MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<4ACCA8F4.5090802@grotto-networking.com> |References:=20<4AAE7742.9090205@grotto-networking.com> =20<4ACC40BA.1030103@cisco.com>=20<4ACCA8F4.5090802@grott o-networking.com>; bh=3RFtoMxVL2Rso6KNmhaagBoghXNd3cKULPZTdSqvJ4o=; b=uC3Acop9aB5Om6FaogbDaO/lca/yXteqfU2SpPpFgR457w/ENIVuMRe6 zUMYhd9KZcaD0K52zmekAxvSGl4fNuDyhRBJipMDqaVHlzRI+FUaaV6Aa BjTC5dFwZI1QtfQrPfcaToQEPdQxm/D/OjlRG7LXeiMMgIx82acTLUKZj s=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoAAIOe0kqQ/uCWe2dsb2JhbACbCgEBFiQGpDGJDwiNRYJFCIFgBA X-IronPort-AV: E=Sophos;i="4.44,544,1249257600"; d="scan'208";a="51525566" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2009 10:15:35 +0000 Received: from [144.254.166.133] (mnza1-dhcp-vl301-144-254-166-133.cisco.com [144.254.166.133]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9CAFT6i017762; Mon, 12 Oct 2009 10:15:29 GMT Message-ID: <4AD301C4.4010808@cisco.com> Date: Mon, 12 Oct 2009 12:15:32 +0200 From: Giovanni Martinelli Organization: Cisco User-Agent: Thunderbird 2.0.0.22 (X11/20090731) MIME-Version: 1.0 To: Greg Bernstein References: <4AAE7742.9090205@grotto-networking.com> <4ACC40BA.1030103@cisco.com> <4ACCA8F4.5090802@grotto-networking.com> In-Reply-To: <4ACCA8F4.5090802@grotto-networking.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: CCAMP Subject: Re: [CCAMP] How to Specify Regeneration at a particular node in RSVP-TE? X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 10:15:49 -0000 Hi Greg, Greg Bernstein wrote: > Hi Giovanni, this information is not needed for the type of RWA for > the WSONs covered in the RWA Framework, RWA Info, or RWA encoding > working group drafts. This means that RWA cannot take into account wavelength conversion (so the model just cover the case where every node can convert wavelengths), right? > It is needed in some network situations covered in the "WSON > compatibility" individual draft and the "WSON Impairments" working > group draft. > > We'll be updating the "WSON compatibility" draft next week to be > explicit as to exactly what extensions are needed in a particular > networking context. > This should have no impact on moving the Framework, Info, and Encoding > drafts towards last call. > yep seen, much clearer... will forward specific comments on that draft Ciao G > Cheers > > Greg > > Giovanni Martinelli wrote: >> Hi Greg, >> >> is this info required for any kind of RWA? >> >> Cheers >> G >> >> Greg Bernstein wrote: >>> Hi folks, we are continuing to investigate the generalization of the >>> WSON work to include regenerators, OEOs and the like. >>> We have a question to how to best indicate via RSVP-TE that a >>> particular processing operation such as regeneration is to take >>> place at >>> a particular node along the path. >>> >>> Previous GMPLS work supports the signaling of wavelength conversion >>> at a particular node along the path since the Explicit Route Object >>> (ERO) supports a label sub-object and one can use a fixed mapping >>> such as [Otani] between labels and wavelengths. >>> >>> If we want to specify other types of processing at a particular node >>> along the path should we define new ERO sub-objects? >>> Another approach seems to be that of RFC5420 concerning LSP >>> attributes. In particular RFC5420 states: >>> 10.2. Communicating to Key Transit LSRs >>> Processing for key transit LSRs (such as ABRs and ASBRs) follows >>> exactly as for egress LSR. The only difference is that the >>> definition of the LSP attribute in the defining RFC will state that >>> the attribute must be acted on by these transit LSRs. >>> Now to use this, it seems that we'd need to include the IP address >>> of the node we want to perform the processing in the TLV, which >>> seems kind of redundant with what we already have in the ERO... >>> >>> Comments, questions, other alternatives? >>> >>> Cheers >>> >>> Greg B. >>> >> >> > From ylee@huawei.com Mon Oct 12 09:10:25 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FDE43A68CC for ; Mon, 12 Oct 2009 09:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vX6n6w9bhh-k for ; Mon, 12 Oct 2009 09:10:24 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 09D413A66B4 for ; Mon, 12 Oct 2009 09:10:24 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRE002YMSXA64@usaga02-in.huawei.com> for ccamp@ietf.org; Mon, 12 Oct 2009 09:10:23 -0700 (PDT) Received: from L73682 ([10.124.12.76]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRE00EWTSX6MW@usaga02-in.huawei.com> for ccamp@ietf.org; Mon, 12 Oct 2009 09:10:22 -0700 (PDT) Date: Mon, 12 Oct 2009 11:10:17 -0500 From: Young Lee In-reply-to: <4ACF7AAE.4000307@grotto-networking.com> To: 'CCAMP' Message-id: <000f01ca4b56$7def5cf0$4c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_0RVM0N1KBS2x7R6veex14A)" Thread-index: AcpJCrpxRL5ypaZfQ2iGUp+kAU9eVgCSzSVA References: <4ACF7AAE.4000307@grotto-networking.com> Subject: Re: [CCAMP] WSON drafts ready for last call... X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 16:10:25 -0000 This is a multi-part message in MIME format. --Boundary_(ID_0RVM0N1KBS2x7R6veex14A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Lou and Deborah, We have updated the WSON RWA framework (04 version) to incorporate a recent comment by Giovanni regarding adding a 4-degree ROADM example. http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-framework-04 Along with info (05) and encode (03), we believe the three WSON drafts are ready for last call. Best Regards, Young _____ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein Sent: Friday, October 09, 2009 1:02 PM To: CCAMP Subject: [CCAMP] WSON drafts ready for last call... Hi CCAMP folks interested in WSON. Thanks for your inputs so far the three fundamental WSON drafts: (a) draft-ietf-ccamp-rwa-wson-framework-03.txt (b) draft-ietf-ccamp-rwa-info-05.txt (c) draft-ietf-ccamp-rwa-wson-encode-03.txt We'd like to last call these soon. So Deborah and Lou will need to let us know the procedures. For those that want to add editorial suggestions and fixes the MS Word versions are available at http://www.grotto-networking.com/wsonOutline and just follow the menu to the particular page related to the draft and all the files can be downloaded. Please turn change tracking on so we can see your suggestions. Best Regards Greg -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --Boundary_(ID_0RVM0N1KBS2x7R6veex14A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Lou and = Deborah,

 

We have updated the WSON RWA = framework (04 version) to incorporate a recent comment by Giovanni regarding adding a 4-degree ROADM example.

 

http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-framework-04

 

Along with info (05) and encode = (03), we believe the three WSON drafts are ready for last call. =

 

Best = Regards,

Young

 

From: ccamp-bounces@ietf.org = [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein
Sent: Friday, October 09, = 2009 1:02 PM
To: CCAMP
Subject: [CCAMP] WSON = drafts ready for last call...

 

Hi CCAMP folks interested in WSON.  = Thanks for your inputs so far the three fundamental WSON drafts:
    (a) draft-ietf-ccamp-rwa-wson-framework-03.txt
    (b) draft-ie= tf-ccamp-rwa-info-05.txt
    (c) d= raft-ietf-ccamp-rwa-wson-encode-03.txt

We'd like to last call these soon. So Deborah and Lou will need to let = us know the procedures.
For those that want to add editorial suggestions and fixes the MS Word = versions are available at
http://www.grotto-n= etworking.com/wsonOutline and just follow the menu to the particular page related to the
draft and all the files can be downloaded. Please turn change tracking = on so we can see your suggestions.

Best Regards

Greg


-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, Grotto Networking (510) =
573-2237
 
--Boundary_(ID_0RVM0N1KBS2x7R6veex14A)-- From gregb@grotto-networking.com Mon Oct 12 10:49:26 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F023828C0F7 for ; Mon, 12 Oct 2009 10:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64-WRyECZrLh for ; Mon, 12 Oct 2009 10:49:24 -0700 (PDT) Received: from mail16c40.carrierzone.com (mail16c40.carrierzone.com [209.235.156.156]) by core3.amsl.com (Postfix) with ESMTP id 4511C28C0ED for ; Mon, 12 Oct 2009 10:49:24 -0700 (PDT) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by mail16c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id n9CHnFiV007808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Oct 2009 17:49:19 GMT Message-ID: <4AD36C16.70804@grotto-networking.com> Date: Mon, 12 Oct 2009 10:49:10 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: George Newsome References: <4AAE7742.9090205@grotto-networking.com> <5292FFA96EC22A4386067E9DBCC0CD2B5DE5B18324@EX-NAP.tellabs-west.tellabsinc.net> <4ACCA9DA.8020407@grotto-networking.com> <004301ca4762$1d22fdc0$32db6a9c@zhang> <4AD0B99F.5060207@ieee.org> In-Reply-To: <4AD0B99F.5060207@ieee.org> Content-Type: multipart/alternative; boundary="------------090608090100040105060806" Cc: CCAMP Subject: Re: [CCAMP] How to Specify Regeneration at a particular node X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 17:49:26 -0000 This is a multi-part message in MIME format. --------------090608090100040105060806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi George, you hit the nail on the head :-) In the revised "WSON compatibility" draft we categorized various network situations (as you say, based on assumptions about equipment types and capabilities) then looked at the implications for path computation, routing and signaling. Only in certain cases would signaling need to be extended. More information maybe needed by path computation (via routing or otherwise) as you point out below. Cheers Greg George Newsome wrote: > Fatai Zhang wrote: >> Hi, Greg and Jonathan, >> >> I think the possible approaches mentioned by Greg are simple and >> useful to resolve the issues. It will make things complex if we use >> EROs to indicate the ports association between server and client >> layer, because how to regenerate the signals is the local matter of >> the node. >> > Hi Greg, Fatai, > > The regen situation is the same as or slightly different from the > wavelength conversion problem depending on your assumptions. > > If you assume that the optical part of your network ONLY carries > ODU's, then you can treat an ODU regenerator as if it is just another > sublayer of an ODU. This is more or less the same as treating the > wavelength as a sublayer of an OCh. However, if you want to allow for > several different digital clients on the optical network, then you > MUST make clear which layer provides the regenerator, and the simple > sublayer model will not work. (You cannot apply an SDH or Ethernet > signal to an ODU regen). > > I think this is a case of the more you can assume, the less you need > to pass around. Or, corollary, the more variation, the more you need > to tell other participants. > > So how regeneration is provided is NOT a local matter, but whether you > need to signal it depends on the amount of variation in digital > clients that you are trying to support. > > I think that allowing for more variation and having a parameter too > many is preferable to making a wrong assumption and having a parameter > too few. > > Regards, > > George > >> Fatai >> >> ----- Original Message ----- From: "Greg Bernstein" >> To: "Sadler, Jonathan B." >> Cc: "CCAMP" Sent: >> Wednesday, October 07, 2009 10:46 PM Subject: Re: [CCAMP] How to >> Specify Regeneration at a particular node inRSVP-TE? >> >> >>> CI? AI? Is the quantum state of a photon preserved though an >>> optical amplifier? Maybe we need a separate draft on quantum >>> communications and encryption and GMPLS. >>> >>> Greg >>> >>> Sadler, Jonathan B. wrote: >>>> Hi Greg, >>>> >>>> Since Regeneration requires termination of the E-M wave which >>>> inherently will cause destruction of CI in order to get at the >>>> AI*, regeneration is a multi-layer interaction. I would suggest >>>> that the EROs would have the ports associated with the >>>> server-to-client layer transition in them (on both the ingress to >>>> the regenerator and the egress from the regenerator) to indicate >>>> invocation of a regenerator. >>>> >>>> Jonathan Sadler >>>> >>>> * One such CI characteristic of the E-M wave that is lost is >>>> photon state. This is e.g. why regeneration cannot be performed >>>> in the middle of a path used for passing cryptographic >>>> information in a quantum-key encryption system. >>>> >>>> -----Original Message----- From: ccamp-bounces@ietf.org >>>> [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein Sent: >>>> Monday, September 14, 2009 12:03 PM To: CCAMP Subject: [CCAMP] >>>> How to Specify Regeneration at a particular node in RSVP-TE? >>>> >>>> Hi folks, we are continuing to investigate the generalization of >>>> the WSON work to include regenerators, OEOs and the like. We have >>>> a question to how to best indicate via RSVP-TE that a particular >>>> processing operation such as regeneration is to take place at a >>>> particular node along the path. >>>> >>>> Previous GMPLS work supports the signaling of wavelength >>>> conversion at a particular node along the path since the Explicit >>>> Route Object (ERO) supports a label sub-object and one can use a >>>> fixed mapping such as [Otani] between labels and wavelengths. >>>> >>>> If we want to specify other types of processing at a particular >>>> node along the path should we define new ERO sub-objects? Another >>>> approach seems to be that of RFC5420 concerning LSP attributes. In >>>> particular RFC5420 states: 10.2. Communicating to Key Transit >>>> LSRs Processing for key transit LSRs (such as ABRs and ASBRs) >>>> follows exactly as for egress LSR. The only difference is that >>>> the definition of the LSP attribute in the defining RFC will >>>> state that the attribute must be acted on by these transit LSRs. >>>> Now to use this, it seems that we'd need to include the IP >>>> address of the node we want to perform the processing in the TLV, >>>> which seems kind of redundant with what we already have in the >>>> ERO... >>>> >>>> Comments, questions, other alternatives? >>>> >>>> Cheers >>>> >>>> Greg B. >>>> >>>> >>> -- =================================================== Dr Greg >>> Bernstein, Grotto Networking (510) 573-2237 >>> >>> >>> _______________________________________________ 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 > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------090608090100040105060806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi George, you hit the nail on the head :-)   In the revised "WSON compatibility" draft we categorized various network situations (as you say, based on assumptions about equipment types and capabilities) then looked at the implications for path computation, routing and signaling. Only in certain cases would signaling need to be extended. More information maybe needed by path computation (via routing or otherwise) as you point out below.

Cheers

Greg

George Newsome wrote:
Fatai Zhang wrote:
Hi, Greg and Jonathan,

I think the possible approaches mentioned by Greg are simple and
useful to resolve the issues. It will make things complex if we use
EROs to indicate the ports association between server and client
layer, because how to regenerate the signals is the local matter of
the node.

Hi Greg, Fatai,

The regen situation is the same as or slightly different from the wavelength conversion problem depending on your assumptions.

If you assume that the optical part of your network ONLY carries ODU's, then you can treat an ODU regenerator as if it is just another sublayer of an ODU. This is more or less the same as treating the wavelength as a sublayer of an OCh. However, if you want to allow for several different digital clients on the optical network, then you MUST make clear which layer provides the regenerator, and the simple sublayer model will not work. (You cannot apply an SDH or Ethernet signal to an ODU regen).

I think this is a case of the more you can assume, the less you need to pass around. Or, corollary, the more variation, the more you need to tell other participants.

So how regeneration is provided is NOT a local matter, but whether you need to signal it depends on the amount of variation in digital clients that you are trying to support.

I think that allowing for more variation and having a parameter too many is preferable to making a wrong assumption and having a parameter too few.

Regards,

    George

Fatai

----- Original Message ----- From: "Greg Bernstein"
<gregb@grotto-networking.com> To: "Sadler, Jonathan B."
<Jonathan.Sadler@tellabs.com> Cc: "CCAMP" <ccamp@ietf.org> Sent:
Wednesday, October 07, 2009 10:46 PM Subject: Re: [CCAMP] How to
Specify Regeneration at a particular node inRSVP-TE?


CI? AI? Is the quantum state of a photon preserved though an
optical amplifier? Maybe we need a separate draft on quantum
communications and encryption and GMPLS.

Greg

Sadler, Jonathan B. wrote:
Hi Greg,

Since Regeneration requires termination of the E-M wave which
inherently will cause destruction of CI in order to get at the
AI*, regeneration is a multi-layer interaction.  I would suggest
that the EROs would have the ports associated with the
server-to-client layer transition in them (on both the ingress to
the regenerator and the egress from the regenerator) to indicate
invocation of a regenerator.

Jonathan Sadler

* One such CI characteristic of the E-M wave that is lost is
photon state.  This is e.g. why regeneration cannot be performed
in the middle of a path used for passing cryptographic
information in a quantum-key encryption system.

-----Original Message----- From: ccamp-bounces@ietf.org
[mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein Sent:
Monday, September 14, 2009 12:03 PM To: CCAMP Subject: [CCAMP]
How to Specify Regeneration at a particular node in RSVP-TE?

Hi folks,  we are continuing to investigate the generalization of
the WSON work to include regenerators, OEOs and the like. We have
a question to how to best indicate via RSVP-TE that a particular
 processing operation such as regeneration is to take place at a
particular node along the path.

Previous GMPLS work supports the signaling of wavelength
conversion at a particular node along the path since the Explicit
Route Object (ERO) supports a label sub-object and one can use a
fixed mapping such as [Otani] between labels and wavelengths.

If we want to specify other types of processing at a particular
node along the path should we define new ERO sub-objects? Another
approach seems to be that of RFC5420 concerning LSP attributes. In particular RFC5420 states: 10.2. Communicating to Key Transit
LSRs Processing for key transit LSRs (such as ABRs and ASBRs)
follows exactly as for egress LSR.  The only difference is that
the definition of the LSP attribute in the defining RFC will
state that the attribute must be acted on by these transit LSRs. Now to use this, it seems that we'd need to include the IP
address of the node we want to perform the processing in the TLV,
which seems kind of redundant  with what we already have in the
ERO...

Comments, questions, other alternatives?

Cheers

Greg B.


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


_______________________________________________ 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 



-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------090608090100040105060806-- From gregb@grotto-networking.com Mon Oct 12 11:01:36 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832863A67D6 for ; Mon, 12 Oct 2009 11:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfAQjrMb5GUA for ; Mon, 12 Oct 2009 11:01:35 -0700 (PDT) Received: from mail32c40.carrierzone.com (mail32c40.carrierzone.com [209.235.156.172]) by core3.amsl.com (Postfix) with ESMTP id 0622F3A682E for ; Mon, 12 Oct 2009 11:01:34 -0700 (PDT) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by mail32c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id n9CI1LBk027140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Oct 2009 18:01:34 GMT Message-ID: <4AD36EF2.7040103@grotto-networking.com> Date: Mon, 12 Oct 2009 11:01:22 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Giovanni Martinelli References: <4AAE7742.9090205@grotto-networking.com> <4ACC40BA.1030103@cisco.com> <4ACCA8F4.5090802@grotto-networking.com> <4AD301C4.4010808@cisco.com> In-Reply-To: <4AD301C4.4010808@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CCAMP Subject: Re: [CCAMP] How to Specify Regeneration at a particular node in RSVP-TE? X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 18:01:36 -0000 Hi Giovanni, the existing RWA (no impairments) drafts don't know about regenerators, i.e., don't model them, but that doesn't mean they are not there. We just assume that the network has been set up in a way such that the signals are "compatible" with the network elements and hence don't need to explicitly include them in the path computation model. While to take advantage of a OEO wavelength converter we do need to know where it is and its properties. GMPLS signaling can allow us to control the conversion process. This is similar to the fact that there may be lots of optical amplifiers (1R regenerators) that we don't know about for control plane purposes. However, for some types of signals (those cool quantum cryto things that Jonathan likes) optical amplifiers may be a problem. However its more 2R and 3R compatibility issues that we are addressing in http://tools.ietf.org/id/draft-bernstein-ccamp-wson-compatibility-01.txt. Cheers Greg Giovanni Martinelli wrote: > Hi Greg, > > Greg Bernstein wrote: > >> Hi Giovanni, this information is not needed for the type of RWA for >> the WSONs covered in the RWA Framework, RWA Info, or RWA encoding >> working group drafts. >> > This means that RWA cannot take into account wavelength conversion (so > the model just cover the case where every node can convert wavelengths), > right? > > > >> It is needed in some network situations covered in the "WSON >> compatibility" individual draft and the "WSON Impairments" working >> group draft. >> >> We'll be updating the "WSON compatibility" draft next week to be >> explicit as to exactly what extensions are needed in a particular >> networking context. >> This should have no impact on moving the Framework, Info, and Encoding >> drafts towards last call. >> >> > yep seen, much clearer... will forward specific comments on that draft > > Ciao > G > > >> Cheers >> >> Greg >> >> Giovanni Martinelli wrote: >> >>> Hi Greg, >>> >>> is this info required for any kind of RWA? >>> >>> Cheers >>> G >>> >>> Greg Bernstein wrote: >>> >>>> Hi folks, we are continuing to investigate the generalization of the >>>> WSON work to include regenerators, OEOs and the like. >>>> We have a question to how to best indicate via RSVP-TE that a >>>> particular processing operation such as regeneration is to take >>>> place at >>>> a particular node along the path. >>>> >>>> Previous GMPLS work supports the signaling of wavelength conversion >>>> at a particular node along the path since the Explicit Route Object >>>> (ERO) supports a label sub-object and one can use a fixed mapping >>>> such as [Otani] between labels and wavelengths. >>>> >>>> If we want to specify other types of processing at a particular node >>>> along the path should we define new ERO sub-objects? >>>> Another approach seems to be that of RFC5420 concerning LSP >>>> attributes. In particular RFC5420 states: >>>> 10.2. Communicating to Key Transit LSRs >>>> Processing for key transit LSRs (such as ABRs and ASBRs) follows >>>> exactly as for egress LSR. The only difference is that the >>>> definition of the LSP attribute in the defining RFC will state that >>>> the attribute must be acted on by these transit LSRs. >>>> Now to use this, it seems that we'd need to include the IP address >>>> of the node we want to perform the processing in the TLV, which >>>> seems kind of redundant with what we already have in the ERO... >>>> >>>> Comments, questions, other alternatives? >>>> >>>> Cheers >>>> >>>> Greg B. >>>> >>>> >>> > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From root@core3.amsl.com Wed Oct 14 12:15:02 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 11DF33A6825; Wed, 14 Oct 2009 12:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091014191502.11DF33A6825@core3.amsl.com> Date: Wed, 14 Oct 2009 12:15:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 19:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework Author(s) : D. Fedyk, et al. Filename : draft-ietf-ccamp-gmpls-ethernet-arch-06.txt Pages : 21 Date : 2009-10-14 There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH), Time-Division Multiplex (TDM) and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized GMPLS based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed and this document provides a framework for these extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ethernet-arch-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-14120052.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Oct 14 14:15:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C520C3A682B; Wed, 14 Oct 2009 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091014211501.C520C3A682B@core3.amsl.com> Date: Wed, 14 Oct 2009 14:15:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-mef-uni-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 21:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI) Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-mef-uni-03.txt Pages : 10 Date : 2009-10-14 This document describes a method for controlling two specific types of Ethernet switching via a Generalized Multi-Protocol Label Switching (GMPLS) based User-Network Interface (UNI). This document supports the types of switching required by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mef-uni-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-mef-uni-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-14141117.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Oct 14 14:15:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CDCB93A69A2; Wed, 14 Oct 2009 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091014211501.CDCB93A69A2@core3.amsl.com> Date: Wed, 14 Oct 2009 14:15:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-dcsc-channel-ext-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 21:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-dcsc-channel-ext-02.txt Pages : 11 Date : 2009-10-14 This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching. The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of an LSP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-dcsc-channel-ext-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-dcsc-channel-ext-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-14141128.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Oct 14 14:15:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D3ABD3A69AB; Wed, 14 Oct 2009 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091014211501.D3ABD3A69AB@core3.amsl.com> Date: Wed, 14 Oct 2009 14:15:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-ether-svcs-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 21:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching Author(s) : L. Berger, D. Fedyk Filename : draft-ietf-ccamp-gmpls-ether-svcs-04.txt Pages : 16 Date : 2009-10-14 This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching corresponding to the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line and Ethernet virtual private line services are covered. Support for MEF and ITU defined parameters is also covered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ether-svcs-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-14141138.I-D@ietf.org> --NextPart-- From lberger@labn.net Thu Oct 15 10:31:08 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A434028C112 for ; Thu, 15 Oct 2009 10:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYrqYtx5hcAE for ; Thu, 15 Oct 2009 10:31:07 -0700 (PDT) Received: from outbound-mail-39.bluehost.com (outbound-mail-39.bluehost.com [69.89.20.193]) by core3.amsl.com (Postfix) with SMTP id DFBA328C140 for ; Thu, 15 Oct 2009 10:31:06 -0700 (PDT) Received: (qmail 30979 invoked by uid 0); 15 Oct 2009 17:31:09 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy2.bluehost.com with SMTP; 15 Oct 2009 17:31:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=X6t56dQePf5LZ2+RIjkd53DOBqDjNECdlODFBgPqNxgITGu8cLhbMfEgb4AUERKuIquKbJr2MhxY5lluZJ7De6hs6Mt3X7Wy74jxf2XsbVp5hJ64mMJrxcoYHS5Uus7W; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MyUAP-0001D4-CL; Thu, 15 Oct 2009 11:31:09 -0600 Message-ID: <4AD74572.2070508@labn.net> Date: Thu, 15 Oct 2009 11:53:22 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: draft-ietf-ccamp-gmpls-g-694-lambda-labels@tools.ietf.org, ccamp@ietf.org X-Enigmail-Version: 0.96a 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] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique resource identification X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 17:31:08 -0000 Authors, Have you given any additional thought on the repesentation of tunable lasers (and unique resource identification) beyond what is currently in the draft? The current text is: If the node has a tunable wavelength transponder, the tuning wavelength is considered as a part of wavelength switching operation. In the past, labels used for TE LSPs always represented a specific resource that is uniquely identifiable by the node that allocates the label and resource. Such unique identification is important/required for certan restart and other corner cases. Your current definition works fine for fixed lasers that can only be mapped to a single fiber. But, the defined global label will not uniquely identify a resource on a node when (a) tunable lasers are used, or (b) when a node supports multiple fixed lasers that can be (optically) switched to a particular output interface. What are your thoughts on how to provide such link-scoped unique resource identification in the context of your draft? I don't think it'll be too difficult to address this critical point, and see a couple of straightforward solutions if you'd like to discuss off-line. Much thanks, Lou From lberger@labn.net Thu Oct 15 11:40:34 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3380C3A6784 for ; Thu, 15 Oct 2009 11:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzS5JWB4e3VN for ; Thu, 15 Oct 2009 11:40:33 -0700 (PDT) Received: from outbound-mail-13.bluehost.com (outbound-mail-13.bluehost.com [69.89.18.113]) by core3.amsl.com (Postfix) with SMTP id 35A273A6767 for ; Thu, 15 Oct 2009 11:40:33 -0700 (PDT) Received: (qmail 13168 invoked by uid 0); 15 Oct 2009 18:40:32 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy1.bluehost.com with SMTP; 15 Oct 2009 18:40:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=PP/ngvmuYhmYatPiAEErkNRuCKugIRqaxqBw/iOGxJ6zln65ArImMFJ5cJK8/BQf2Vr5/iweM202agiyTZ1DiEE8wvlUwuZvkIwsdZsDQpnMoOwQCeGOUNLHepYjpsGR; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1MyVFY-0006fD-7Q; Thu, 15 Oct 2009 12:40:32 -0600 Message-ID: <4AD76CB3.2020408@labn.net> Date: Thu, 15 Oct 2009 14:40:51 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Greg Bernstein References: <4AAE7742.9090205@grotto-networking.com> In-Reply-To: <4AAE7742.9090205@grotto-networking.com> X-Enigmail-Version: 0.96a 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] How to Specify Regeneration at a particular node in RSVP-TE? X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 18:40:34 -0000 Greg, I think we need a wider discussion on where regen (and to some degree conversion) fits into the WSON model being progressed by the WG. (nor on that in a separate mail) I think this is in line with some of there other comments on this thread. WRT the specific point of encoding: Assuming we agree on function, don't forget about the reserved bits in the label ERO subobject and perhaps even in the Otani label itself... Lou On 9/14/2009 1:02 PM, Greg Bernstein wrote: > Hi folks, we are continuing to investigate the generalization of the > WSON work to include regenerators, OEOs and the like. > We have a question to how to best indicate via RSVP-TE that a particular > processing operation such as regeneration is to take place at > a particular node along the path. > > Previous GMPLS work supports the signaling of wavelength conversion at a > particular node along the path since the Explicit Route Object (ERO) > supports a label sub-object and one can use a fixed mapping such as > [Otani] between labels and wavelengths. > > If we want to specify other types of processing at a particular node > along the path should we define new ERO sub-objects? > Another approach seems to be that of RFC5420 concerning LSP attributes. > In particular RFC5420 states: > 10.2. Communicating to Key Transit LSRs > Processing for key transit LSRs (such as ABRs and > ASBRs) follows > exactly as for egress LSR. The only difference is > that the > definition of the LSP attribute in the defining RFC > will state that > the attribute must be acted on by these transit LSRs. > Now to use this, it seems that we'd need to include the IP address of > the node we want to perform the processing in the TLV, which seems kind > of redundant with what we already have in the ERO... > > Comments, questions, other alternatives? > > Cheers > > Greg B. > From ylee@huawei.com Thu Oct 15 13:09:38 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1E9D3A690D for ; Thu, 15 Oct 2009 13:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.554 X-Spam-Level: X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3L4NwXWgIIk for ; Thu, 15 Oct 2009 13:09:38 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id E795E3A657C for ; Thu, 15 Oct 2009 13:09:37 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRK00G1EO04CZ@usaga04-in.huawei.com> for ccamp@ietf.org; Thu, 15 Oct 2009 15:09:41 -0500 (CDT) Received: from L73682 ([10.192.220.107]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRK00HP4NZZUT@usaga04-in.huawei.com> for ccamp@ietf.org; Thu, 15 Oct 2009 15:09:40 -0500 (CDT) Date: Thu, 15 Oct 2009 15:09:35 -0500 From: Young Lee In-reply-to: <4AD76CB3.2020408@labn.net> To: 'Lou Berger' , 'Greg Bernstein' Message-id: <000a01ca4dd3$6b6834b0$6bdcc00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpNxzU14yKMvU5BQyaS3ZtoQzOpRQAChl1g References: <4AAE7742.9090205@grotto-networking.com> <4AD76CB3.2020408@labn.net> Cc: 'CCAMP' Subject: Re: [CCAMP] How to Specify Regeneration at a particular node inRSVP-TE? X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 20:09:38 -0000 Hi Lou, To address the issue of signal processing/compatibility and network element compatibility to multiple signals for Regenerators, OEO and Wavelength converters, we recently updated the following draft: http://tools.ietf.org/id/draft-bernstein-ccamp-wson-compatibility-01.txt We have separated this work from RWA and Impairment because this deserves a special attention. This draft addresses where regeneration and other translucent networks fit into the WSON model. Hope this will generate more attention and discussion in the WG. Regards, Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger Sent: Thursday, October 15, 2009 1:41 PM To: Greg Bernstein Cc: CCAMP Subject: Re: [CCAMP] How to Specify Regeneration at a particular node inRSVP-TE? Greg, I think we need a wider discussion on where regen (and to some degree conversion) fits into the WSON model being progressed by the WG. (nor on that in a separate mail) I think this is in line with some of there other comments on this thread. WRT the specific point of encoding: Assuming we agree on function, don't forget about the reserved bits in the label ERO subobject and perhaps even in the Otani label itself... Lou On 9/14/2009 1:02 PM, Greg Bernstein wrote: > Hi folks, we are continuing to investigate the generalization of the > WSON work to include regenerators, OEOs and the like. > We have a question to how to best indicate via RSVP-TE that a particular > processing operation such as regeneration is to take place at > a particular node along the path. > > Previous GMPLS work supports the signaling of wavelength conversion at a > particular node along the path since the Explicit Route Object (ERO) > supports a label sub-object and one can use a fixed mapping such as > [Otani] between labels and wavelengths. > > If we want to specify other types of processing at a particular node > along the path should we define new ERO sub-objects? > Another approach seems to be that of RFC5420 concerning LSP attributes. > In particular RFC5420 states: > 10.2. Communicating to Key Transit LSRs > Processing for key transit LSRs (such as ABRs and > ASBRs) follows > exactly as for egress LSR. The only difference is > that the > definition of the LSP attribute in the defining RFC > will state that > the attribute must be acted on by these transit LSRs. > Now to use this, it seems that we'd need to include the IP address of > the node we want to perform the processing in the TLV, which seems kind > of redundant with what we already have in the ERO... > > Comments, questions, other alternatives? > > Cheers > > Greg B. > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From root@core3.amsl.com Thu Oct 15 19:00:02 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 122B13A69A8; Thu, 15 Oct 2009 19:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091016020002.122B13A69A8@core3.amsl.com> Date: Thu, 15 Oct 2009 19:00:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 02:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) control of Ethernet PBB-TE Author(s) : D. Fedyk, et al. Filename : draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt Pages : 19 Date : 2009-10-15 This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework [ARCH] and describes the technology specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point to point (P2P) and point to multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-15184951.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Oct 16 14:45:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6FF223A67DB; Fri, 16 Oct 2009 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091016214501.6FF223A67DB@core3.amsl.com> Date: Fri, 16 Oct 2009 14:45:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D ACTION:draft-ietf-ccamp-gmpls-mln-extensions-08.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 21:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) Author(s) : D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, J. Le Roux Filename : draft-ietf-ccamp-gmpls-mln-extensions-08.txt Pages : 22 Date : 2009-10-16 There are specific requirements for the support of networks comprising Label Switching Routers (LSR) participating in different data plane switching layers controlled by a single Generalized Multi Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks/Multi-Region Networks (MLN/MRN). This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer/Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple LSP regions or layers within a single TE domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-extensions-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-mln-extensions-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-16143220.I-D@ietf.org> --NextPart-- From loa@pi.nu Sun Oct 18 10:49:03 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB36E3A6968; Sun, 18 Oct 2009 10:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmxeYSxkCgmR; Sun, 18 Oct 2009 10:49:03 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id ED8413A6903; Sun, 18 Oct 2009 10:49:02 -0700 (PDT) Received: from [192.168.0.100] (h133n2fls33o883.telia.com [217.208.62.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 94CCED404F; Sun, 18 Oct 2009 19:49:06 +0200 (CEST) Message-ID: <4ADB550F.8080507@pi.nu> Date: Sun, 18 Oct 2009 19:49:03 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" , "mpls-tp@ietf.org" , pwe3@ietf.org, ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 17:49:03 -0000 Working Group, the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have asked that the draft is adopted as an mpls working group document. This mail starts a two week poll on making the draft a working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content should be sent to the same mailing list with a different subject line. The poll ends Fri Oct 30. Loa and George MPLS working group co-chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From nurit.sprecher@nsn.com Sun Oct 18 13:54:00 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59DC3A6973; Sun, 18 Oct 2009 13:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htn0a0KwFcSQ; Sun, 18 Oct 2009 13:54:00 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id CC5993A692B; Sun, 18 Oct 2009 13:53:59 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9IKs49n002390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 18 Oct 2009 22:54:04 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9IKs4CV031028; Sun, 18 Oct 2009 22:54:04 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Oct 2009 22:54:03 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Oct 2009 22:54:01 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A532640167C84B@DEMUEXC014.nsn-intra.net> In-Reply-To: <4ADB550F.8080507@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft Thread-Index: AcpQG0+FM5Zn/e/wQLinfcxVsnzJpgAGcpkw References: <4ADB550F.8080507@pi.nu> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Loa Andersson" , , , , X-OriginalArrivalTime: 18 Oct 2009 20:54:03.0894 (UTC) FILETIME=[204DD160:01CA5035] Subject: Re: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 20:54:00 -0000 Yes, support -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Sunday, October 18, 2009 7:49 PM To: mpls-tp@ietf.org; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org Subject: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft Working Group, the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have asked that the draft is adopted as an mpls working group document. This mail starts a two week poll on making the draft a working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content should be sent to the same mailing list with a different subject line. The poll ends Fri Oct 30. Loa and George MPLS working group co-chairs --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From gregimirsky@gmail.com Sun Oct 18 15:34:27 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A8D128C11C; Sun, 18 Oct 2009 15:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Otvt3Hk7EinR; Sun, 18 Oct 2009 15:34:26 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 7805F28C11B; Sun, 18 Oct 2009 15:34:25 -0700 (PDT) Received: by fxm18 with SMTP id 18so4397954fxm.37 for ; Sun, 18 Oct 2009 15:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=06fTkvy75ZwxhLUPM0m0xNxzd8WwdUP3ZwNyZZ0E3YI=; b=Fc/cYjRA3KK20D0Bt1qAJ1qMnWbMnmNZZxh3MSD7TvQ0TdWPM6woC08CsWD9dYOP9h PKo59PejEzjHqLSH2lPIe1uayETtsPOHPD02rfGzbmOsB/+1/jw57KBaV0wOavaxqIRO spAr81jH6Wmy1UlFUpz4IvBtWxYoU9D1WZgcc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TIrdlTWDXF94FXpZtXinErAI8IyWZ8HArHrwRm+6ND/mrQQDdZxeycpkDZpvC0SysW FeCNd11bCStBrMgu+8wE83p27fipaEF0fwgwEqqXirf8FPg94SASdEY0VEwFGoJ6LbUX VoFanTNcJbpz4KUzZ7nmHV7o9LN+Pt+26T31I= MIME-Version: 1.0 Received: by 10.204.15.24 with SMTP id i24mr590593bka.2.1255905267422; Sun, 18 Oct 2009 15:34:27 -0700 (PDT) In-Reply-To: <4ADB550F.8080507@pi.nu> References: <4ADB550F.8080507@pi.nu> Date: Sun, 18 Oct 2009 15:34:27 -0700 Message-ID: <787be2780910181534v6dd4502eo32981536f23d834b@mail.gmail.com> From: Greg Mirsky To: Loa Andersson Content-Type: multipart/alternative; boundary=00032555af0e56188704763d3bd4 Cc: ccamp@ietf.org, pwe3@ietf.org, "mpls-tp@ietf.org" Subject: Re: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2009 22:34:27 -0000 --00032555af0e56188704763d3bd4 Content-Type: text/plain; charset=ISO-8859-1 support On Sun, Oct 18, 2009 at 10:49 AM, Loa Andersson wrote: > Working Group, > > the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have > asked that the draft is adopted as an mpls working group document. > > This mail starts a two week poll on making the draft a working group > document. Send a mail to the mpls-tp@ietf.org mailing list, indicating > "yes/support" or "no/do not support". > > Comments on the content should be sent to the same mailing list with > a different subject line. > > The poll ends Fri Oct 30. > > Loa and George > MPLS working group co-chairs > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --00032555af0e56188704763d3bd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable support

On Sun, Oct 18, 2009 at 10:49 AM,= Loa Andersson <loa@pi.nu= > wrote:
Working Group,

the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have
asked that the draft is adopted as an mpls working group document.

This mail starts a two week poll on making the draft a working group
document. Send a mail to the mpls-tp@ietf.org mailing list, indicating
"yes/support" or "no/do not support".

Comments on the content should be sent to the same mailing list with
a different subject line.

The poll ends Fri Oct 30.

Loa and George
MPLS working group co-chairs

--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@eri= csson.com
Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 = 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +46 767 72 92 13
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp

--00032555af0e56188704763d3bd4-- From tom.nadeau@bt.com Sun Oct 18 17:26:57 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BFE03A67EB; Sun, 18 Oct 2009 17:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.532 X-Spam-Level: X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgptGLepeXGe; Sun, 18 Oct 2009 17:26:56 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 9D5D13A67AE; Sun, 18 Oct 2009 17:26:56 -0700 (PDT) Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.103]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 01:27:01 +0100 Received: from 217.32.164.181 ([217.32.164.181]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.150]) with Microsoft Exchange Server HTTP-DAV ; Mon, 19 Oct 2009 00:27:01 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Sun, 18 Oct 2009 20:27:00 -0400 From: "Thomas D. Nadeau" To: Loa Andersson , "mpls-tp@ietf.org" , , Message-ID: Thread-Topic: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft Thread-Index: AcpQUt90+CnF6qCrx0eiN95pwImunA== In-Reply-To: <4ADB550F.8080507@pi.nu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Oct 2009 00:27:01.0805 (UTC) FILETIME=[E0884DD0:01CA5052] Subject: Re: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 00:26:57 -0000 As I said earlier, I do not see the point in bringing this document forward. I viewed it more as a set of meeting minutes/notes that were held by the MEAD team, and as such has served its purpose. --Tom On 10/18/09 1:49 PM, "Loa Andersson" wrote: > Working Group, > > the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have > asked that the draft is adopted as an mpls working group document. > > This mail starts a two week poll on making the draft a working group > document. Send a mail to the mpls-tp@ietf.org mailing list, indicating > "yes/support" or "no/do not support". > > Comments on the content should be sent to the same mailing list with > a different subject line. > > The poll ends Fri Oct 30. > > Loa and George > MPLS working group co-chairs -- Principal Architect - 21CN Networks From gregimirsky@gmail.com Sun Oct 18 18:38:06 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 553DC28C0F3; Sun, 18 Oct 2009 18:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWtppPMfWsTF; Sun, 18 Oct 2009 18:38:05 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id BF4F128C0CE; Sun, 18 Oct 2009 18:38:04 -0700 (PDT) Received: by fxm18 with SMTP id 18so4495411fxm.37 for ; Sun, 18 Oct 2009 18:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MACJiF6fTAWQjwh+ZB81e292q92mcLg+t5TD4lQW42c=; b=MMmTm67+NSYBwEHjDbTCk4AelfhaLYinN7oYOJ9LxIQiBEJp4UguGPVxuQfsFWwKH5 4bC68ZThf9yv0FnQTJTvXbO+T5HR+Njp0jhDv+8BGuDbfyryh5OH6P0EMYXbBGCdc7QC g2wvn7u8IVvcyDiyC6IEXpfSUn9s9qhcfFhWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UMHVFN/n+FXxR2LoHIhx8gPhiToNd+6wW3tnETyZ2Qe7OwBcipGQvVZbAYeCho2wOZ H5UQwD7UsPlOv7/hhQEjHUqpRloTjpfq1gV6DUsx90uBHdYCLxiHViJggo6Cu/DLvetM 6U3ykfV+arNQnwfwVC2TNS43Lp1wAW9+kPFDQ= MIME-Version: 1.0 Received: by 10.204.155.65 with SMTP id r1mr4184042bkw.143.1255916287345; Sun, 18 Oct 2009 18:38:07 -0700 (PDT) In-Reply-To: References: <4ADB550F.8080507@pi.nu> Date: Sun, 18 Oct 2009 18:38:07 -0700 Message-ID: <787be2780910181838x2bd76bd4va451344bb69cbc05@mail.gmail.com> From: Greg Mirsky To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=00151747afcc2cc51704763fccb2 Cc: ccamp@ietf.org, "mpls-tp@ietf.org" , pwe3@ietf.org Subject: Re: [CCAMP] [mpls-tp] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 01:38:06 -0000 --00151747afcc2cc51704763fccb2 Content-Type: text/plain; charset=ISO-8859-1 I think that it would be useful and helpful to progress this document as Informational. Regards, greg On Sun, Oct 18, 2009 at 5:27 PM, Thomas D. Nadeau wrote: > > As I said earlier, I do not see the point in bringing this document > forward. I viewed it more as a set of meeting minutes/notes that were held > by the MEAD team, and as such has served its purpose. > > --Tom > > > > On 10/18/09 1:49 PM, "Loa Andersson" wrote: > > > Working Group, > > > > the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have > > asked that the draft is adopted as an mpls working group document. > > > > This mail starts a two week poll on making the draft a working group > > document. Send a mail to the mpls-tp@ietf.org mailing list, indicating > > "yes/support" or "no/do not support". > > > > Comments on the content should be sent to the same mailing list with > > a different subject line. > > > > The poll ends Fri Oct 30. > > > > Loa and George > > MPLS working group co-chairs > > -- > Principal Architect - 21CN Networks > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > --00151747afcc2cc51704763fccb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that it would be useful and helpful to progress this document as In= formational.

Regards,
greg

On S= un, Oct 18, 2009 at 5:27 PM, Thomas D. Nadeau <tom.nadeau@bt.com> wrote:

=A0 =A0As I said earlier, I do not see the point in bringing this document=
forward. I viewed it more as a set of meeting minutes/notes that were held<= br> by the MEAD team, and as such has served its purpose.

=A0 =A0--Tom



On 10/18/09 1:49 PM, "Loa Andersson" <loa@pi.nu> wrote:

> Working Group,
>
> the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have
> asked that the draft is adopted as an mpls working group document.
>
> This mail starts a two week poll on making the draft a working group > document. Send a mail to the mpls-= tp@ietf.org mailing list, indicating
> "yes/support" or "no/do not support".
>
> Comments on the content should be sent to the same mailing list with > a different subject line.
>
> The poll ends Fri Oct 30.
>
> Loa and George
> MPLS working group co-chairs

--
Principal Architect - 21CN Networks


_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp

--00151747afcc2cc51704763fccb2-- From Jonathan.Sadler@tellabs.com Mon Oct 19 03:27:50 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABA143A6935; Mon, 19 Oct 2009 03:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxyhVRje--Gv; Mon, 19 Oct 2009 03:27:49 -0700 (PDT) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id ACE253A691D; Mon, 19 Oct 2009 03:27:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,584,1249257600"; d="scan'208";a="1299381352" Received: from usnvwwmspht02.hq.tellabs.com (HELO usnvwwmspht02.tellabs-west.tellabsinc.net) ([172.23.211.70]) by mx4-priv.tellabs.com with ESMTP; 19 Oct 2009 10:26:49 +0000 Received: from EX-NAP.tellabs-west.tellabsinc.net ([172.23.211.71]) by usnvwwmspht02.tellabs-west.tellabsinc.net ([172.23.211.70]) with mapi; Mon, 19 Oct 2009 05:26:48 -0500 From: "Sadler, Jonathan B." To: "Thomas D. Nadeau" , Loa Andersson , "mpls-tp@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Date: Mon, 19 Oct 2009 05:22:29 -0500 Thread-Topic: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft Thread-Index: AcpQUt90+CnF6qCrx0eiN95pwImunAAUzBEq Message-ID: <5292FFA96EC22A4386067E9DBCC0CD2B5DE5591C1F@EX-NAP.tellabs-west.tellabsinc.net> References: <4ADB550F.8080507@pi.nu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 10:27:50 -0000 I agree with Tom that this document seems to be more of a set of meeting mi= nutes/notes. I don't see any reasoned analysis - just a statement of what = is different between the two mechanisms and the requirements along with a r= ecommendation. The fact no discussion of inter-layer interactions is shown in this documen= t really concerns me as I believe its missing a key difference between the = approaches catalogued. If the document contained reasoned analysis and delt with all issues, I wou= ld be able to support it. But in its current form it is lacking the requir= ed substance. Jonathan Sadler ________________________________________ From: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] On Behalf Of Thomas D= . Nadeau [tom.nadeau@bt.com] Sent: Sunday, October 18, 2009 7:27 PM To: Loa Andersson; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org Subject: Re: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.= txt a working group draft As I said earlier, I do not see the point in bringing this document forward. I viewed it more as a set of meeting minutes/notes that were held by the MEAD team, and as such has served its purpose. --Tom On 10/18/09 1:49 PM, "Loa Andersson" wrote: > Working Group, > > the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have > asked that the draft is adopted as an mpls working group document. > > This mail starts a two week poll on making the draft a working group > document. Send a mail to the mpls-tp@ietf.org mailing list, indicating > "yes/support" or "no/do not support". > > Comments on the content should be sent to the same mailing list with > a different subject line. > > The poll ends Fri Oct 30. > > Loa and George > MPLS working group co-chairs -- Principal Architect - 21CN Networks _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp= From loa@pi.nu Mon Oct 19 03:42:28 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F5863A67A3; Mon, 19 Oct 2009 03:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIe3vjbV1DYN; Mon, 19 Oct 2009 03:42:27 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 213D43A67E6; Mon, 19 Oct 2009 03:42:27 -0700 (PDT) Received: from [192.36.158.106] (wdhcp-158-106.verkstad.net [192.36.158.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 36160D4057; Mon, 19 Oct 2009 12:42:32 +0200 (CEST) Message-ID: <4ADC4297.7050009@pi.nu> Date: Mon, 19 Oct 2009 12:42:31 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ccamp@ietf.org, pwe3@ietf.org, 'MPLS-TP ad hoc' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] mpls working last call on upstream label allocation X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 10:42:28 -0000 All, this is to inform you that the mpls wg has started a working group last call on: draft-ietf-mpls-ldp-upstream-04 draft-ietf-mpls-rsvp-upstream-04 Please review and send comments to the mpls wg mailing list (mpls@ietf.org). /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From agmalis@gmail.com Mon Oct 19 04:50:52 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD94E3A686D; Mon, 19 Oct 2009 04:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fEgavQoGn-a; Mon, 19 Oct 2009 04:50:52 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id A85B23A67D7; Mon, 19 Oct 2009 04:50:51 -0700 (PDT) Received: by ywh13 with SMTP id 13so5985804ywh.29 for ; Mon, 19 Oct 2009 04:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=vD1mgnrzgCGQdRoTiTAbNzxVVl/psWQm4glyHW4Lo40=; b=ikUdmQY0uObmaai7sMxBOGSftY+7DhDkXyk9AIeLKG3/gaFexnv2iNX4y68VbsXJwz D69cp4sRbwtLTFter7VoF4lgzcsA4QvUc4ULDfgu3UJGpOJLbRIxijTyJ+EasFXJJNob QfW1DSl6bvm+eJG23x/vI6BT3n3nlEjN30qzI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=YUbE8BOUMtH/rJaxST1Ye3EsOydgG5uRK4HA5iyHavatS1iWBsCVbKvrJcz9bxTvZa anT3OneXqhWHcp21M723PwSEFXDeZrBiTdJjpJXLeottksmZYMLPNlCHwn+//v/Zl4mY lLYxCa4eirMup1eDC1HHvuZvH95ThYNn7VpnQ= MIME-Version: 1.0 Received: by 10.101.131.20 with SMTP id i20mr3167238ann.114.1255953055087; Mon, 19 Oct 2009 04:50:55 -0700 (PDT) In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2B5DE5591C1F@EX-NAP.tellabs-west.tellabsinc.net> References: <4ADB550F.8080507@pi.nu> <5292FFA96EC22A4386067E9DBCC0CD2B5DE5591C1F@EX-NAP.tellabs-west.tellabsinc.net> From: "Andrew G. Malis" Date: Mon, 19 Oct 2009 07:50:35 -0400 Message-ID: <8c99930d0910190450k1869f0efv11751094902ece05@mail.gmail.com> To: "Sadler, Jonathan B." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ccamp@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 11:50:52 -0000 Jonathan, The question isn't if the document is ready for publication, but whether the contents should now reflect WG consensus. It's very much open for any text that you would like to contribute on inter-layer interactions. Cheers, Andy On Mon, Oct 19, 2009 at 6:22 AM, Sadler, Jonathan B. wrote: > I agree with Tom that this document seems to be more of a set of meeting = minutes/notes. =A0I don't see any reasoned analysis - just a statement of w= hat is different between the two mechanisms and the requirements along with= a recommendation. > > The fact no discussion of inter-layer interactions is shown in this docum= ent really concerns me as I believe its missing a key difference between th= e approaches catalogued. > > If the document contained reasoned analysis and delt with all issues, I w= ould be able to support it. =A0But in its current form it is lacking the re= quired substance. > > Jonathan Sadler > > ________________________________________ > From: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] On Behalf Of Thomas= D. Nadeau [tom.nadeau@bt.com] > Sent: Sunday, October 18, 2009 7:27 PM > To: Loa Andersson; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: Re: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-0= 7.txt a working group draft > > =A0 =A0As I said earlier, I do not see the point in bringing this documen= t > forward. I viewed it more as a set of meeting minutes/notes that were hel= d > by the MEAD team, and as such has served its purpose. > > =A0 =A0--Tom > > > > On 10/18/09 1:49 PM, "Loa Andersson" wrote: > >> Working Group, >> >> the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have >> asked that the draft is adopted as an mpls working group document. >> >> This mail starts a two week poll on making the draft a working group >> document. Send a mail to the mpls-tp@ietf.org mailing list, indicating >> "yes/support" or "no/do not support". >> >> Comments on the content should be sent to the same mailing list with >> a different subject line. >> >> The poll ends Fri Oct 30. >> >> Loa and George >> MPLS working group co-chairs > > -- > Principal Architect - 21CN Networks > > > _______________________________________________ > 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 root@core3.amsl.com Mon Oct 19 07:00:02 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 31BB53A68A0; Mon, 19 Oct 2009 07:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091019140002.31BB53A68A0@core3.amsl.com> Date: Mon, 19 Oct 2009 07:00:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-hierarchy-bis-07.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 14:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Procedures for Dynamically Signaled Hierarchical Label Switched Paths Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-lsp-hierarchy-bis-07.txt Pages : 29 Date : 2009-10-19 Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks. Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle TE links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process. The mechanisms defined in this document deprecates the technique for the signaling of LSPs that are to be used as numbered TE links described in RFC 4206.Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-lsp-hierarchy-bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-19065244.I-D@ietf.org> --NextPart-- From nurit.sprecher@nsn.com Mon Oct 19 07:42:09 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A068128C138; Mon, 19 Oct 2009 07:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXTedMXQSOMF; Mon, 19 Oct 2009 07:42:08 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id D550928C147; Mon, 19 Oct 2009 07:42:07 -0700 (PDT) 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 n9JEgCtR014769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2009 16:42:12 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9JEgBZE015953; Mon, 19 Oct 2009 16:42:11 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 16:42:11 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA50CA.570AADB2" Date: Mon, 19 Oct 2009 16:42:10 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264016B2516@DEMUEXC014.nsn-intra.net> In-Reply-To: <48E7911F78327A449A9FB956376672862B104DAA@exrad4.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft Thread-Index: AcpQw09zu7QokPAtSQ6f+YqfhJBh5AABFNSA References: <48E7911F78327A449A9FB956376672862B104DAA@exrad4.ad.rad.co.il> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Yaakov Stein" , X-OriginalArrivalTime: 19 Oct 2009 14:42:11.0236 (UTC) FILETIME=[57562640:01CA50CA] Cc: ccamp@ietf.org, pwe3@ietf.org Subject: Re: [CCAMP] [mpls-tp] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 14:42:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA50CA.570AADB2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yaacov, Thanks for the hint. We will refer to these mechanisms in our next version. Best regards, Nurit =20 ________________________________ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Yaakov Stein Sent: Monday, October 19, 2009 3:52 PM To: mpls-tp@ietf.org Cc: ccamp@ietf.org; pwe3@ietf.org Subject: Re: [mpls-tp] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft =20 Support. =20 Although there are some glaring errors. For example, for packet loss and delay there is a statement=20 There is no mechanism defined in the IETF to support this function. =20 I think the authors should look at the RFCs produced by IPPM, and in fact I think that OWAMP and/or TWAMP could be considered as an alternative to Y.1731 mechanisms. =20 Y(J)S =20 ------_=_NextPart_001_01CA50CA.570AADB2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Yaacov,

Thanks for the = hint.

We will refer to these mechanisms = in our next version.

Best = regards,

Nurit

 

From: = mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of ext Yaakov = Stein
Sent: Monday, October 19, = 2009 3:52 PM
To: mpls-tp@ietf.org
Cc: ccamp@ietf.org; = pwe3@ietf.org
Subject: Re: [mpls-tp] = poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group = draft

 

Support.

 

Although there are some glaring errors.

For example, for packet loss and delay there is a statement =

   There is no mechanism defined in the IETF to support this = function.

 

I think the authors should look at the RFCs produced by = IPPM,

and in fact I think that OWAMP and/or TWAMP could be considered as an = alternative to Y.1731 mechanisms.

 

Y(J)S

 

------_=_NextPart_001_01CA50CA.570AADB2-- From adrian@olddog.co.uk Mon Oct 19 07:50:38 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 352FA28C165 for ; Mon, 19 Oct 2009 07:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.503 X-Spam-Level: X-Spam-Status: No, score=-1.503 tagged_above=-999 required=5 tests=[AWL=1.095, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPVUB3-vzffn for ; Mon, 19 Oct 2009 07:50:37 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 2D4AE28C0FA for ; Mon, 19 Oct 2009 07:50:37 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id n9JEoPwp009929 for ; Mon, 19 Oct 2009 15:50:30 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id n9JEoOmL009922 for ; Mon, 19 Oct 2009 15:50:24 +0100 Message-ID: <17B241968C63467C8C8F14C3F22C970D@your029b8cecfe> From: "Adrian Farrel" To: References: <20091019140002.31BB53A68A0@core3.amsl.com> Date: Mon, 19 Oct 2009 15:44:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-hierarchy-bis-07.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 14:50:38 -0000 Hi, This update captures some comments made by the WG chairs as they reviewed the document post-WG last call. The changes are all editorial for clarification. Adrian >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 : Procedures for Dynamically Signaled Hierarchical Label > Switched Paths > Author(s) : K. Shiomoto, et al. > Filename : draft-ietf-ccamp-lsp-hierarchy-bis-07.txt > Pages : 29 > Date : 2009-10-19 > > Label Switched Paths (LSPs) set up in Multiprotocol Label Switching > (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links > to carry traffic in those networks or in other (client) networks. > > Protocol mechanisms already exist to facilitate the establishment of > such LSPs and to bundle TE links to reduce the load on routing > protocols. This document defines extensions to those mechanisms to > support identifying the use to which such LSPs are to be put and to > enable the TE link endpoints to be assigned addresses or unnumbered > identifiers during the signaling process. > > The mechanisms defined in this document deprecates the technique > for the signaling of LSPs that are to be used as numbered TE links > described in RFC 4206.Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-07.txt From mtylenda@isocore.com Mon Oct 19 14:02:59 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2AC3A67FF for ; Mon, 19 Oct 2009 14:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.704 X-Spam-Level: *** X-Spam-Status: No, score=3.704 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_102=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUQszjM+A388 for ; Mon, 19 Oct 2009 14:02:58 -0700 (PDT) Received: from ns1.cpanel.btnaccess.com (unknown [205.177.121.254]) by core3.amsl.com (Postfix) with ESMTP id 8392C3A683C for ; Mon, 19 Oct 2009 14:02:56 -0700 (PDT) Received: from [65.213.193.106] (helo=[127.0.0.1]) by ns1.cpanel.btnaccess.com with esmtpa (Exim 4.69) (envelope-from ) id 1MzzNg-0003HC-HL for ccamp@ietf.org; Mon, 19 Oct 2009 17:03:04 -0400 Message-ID: <4ADCD3F0.3000406@isocore.com> Date: Mon, 19 Oct 2009 17:02:40 -0400 From: Matt Tylenda User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com Subject: [CCAMP] MPLS 2009 International Conference: Register Now! X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 21:02:59 -0000 The 12th annual MPLS 2009 is set to open on October 25, 2009 in Washington,DC The technical program details and sponsors list is available at www.mpls2009.com Registration is still open - http://www.isocore.com/mpls2009/registration/attendees.htm We look forward to seeing you at the show! -Matt From stbryant@cisco.com Sun Oct 18 23:49:55 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D300E3A67AB; Sun, 18 Oct 2009 23:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYY+9XLW2ohy; Sun, 18 Oct 2009 23:49:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5598A3A68A4; Sun, 18 Oct 2009 23:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=585; q=dns/txt; s=amsiport01001; t=1255935001; x=1257144601; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Stewart=20Bryant=20 |Reply-To:=20stbryant@cisco.com|Subject:=20Re:=20[mpls-tp ]=20poll=20on=20making=20draft-sprecher-mpls-tp-oam-analy sis-07.txt=0D=0A=20a=20working=20group=20draft|Date:=20Mo n,=2019=20Oct=202009=2007:49:52=20+0100|Message-ID:=20<4A DC0C10.9090409@cisco.com>|To:=20Loa=20Andersson=20|CC:=20"mpls-tp@ietf.org"=20,=20pwe 3@ietf.org,=20ccamp@ietf.org|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<4ADB55 0F.8080507@pi.nu>|References:=20<4ADB550F.8080507@pi.nu>; bh=sv3hAmWY9DFNxBLDrJP4Oe1U6vMqeXXj0ZQayC4Naco=; b=GZgh8Ui4m9FTbBEjKRzy6S/bpyitiutfAgf2ZFZz0zzts2KS7ECAYmKd oVsSYza3EJX+RPZYeuEamD+Ju+bwoCttDrCU5t5XfUsdhspABDgKcWppc 4LrG6RBnLzZfof64CgGIsnnGKPHRtwsAik5jxr87TFoLpWnKGtHUK/TLb M=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEAADKp20qQ/uCWe2dsb2JhbACbEAEBFiQGpmuBGQgBlRiEMQQ X-IronPort-AV: E=Sophos;i="4.44,584,1249257600"; d="scan'208";a="52108192" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Oct 2009 06:49:53 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9J6nrCJ019018; Mon, 19 Oct 2009 06:49:53 GMT Received: from Stewarts-Computer-2.local (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n9J6nqD08644; Mon, 19 Oct 2009 07:49:52 +0100 (BST) Message-ID: <4ADC0C10.9090409@cisco.com> Date: Mon, 19 Oct 2009 07:49:52 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Loa Andersson References: <4ADB550F.8080507@pi.nu> In-Reply-To: <4ADB550F.8080507@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 19 Oct 2009 14:35:23 -0700 Cc: ccamp@ietf.org, pwe3@ietf.org, "mpls-tp@ietf.org" Subject: Re: [CCAMP] [mpls-tp] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 06:49:55 -0000 Support - Stewart Loa Andersson wrote: > Working Group, > > the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have > asked that the draft is adopted as an mpls working group document. > > This mail starts a two week poll on making the draft a working group > document. Send a mail to the mpls-tp@ietf.org mailing list, indicating > "yes/support" or "no/do not support". > > Comments on the content should be sent to the same mailing list with > a different subject line. > > The poll ends Fri Oct 30. > > Loa and George > MPLS working group co-chairs > From yaakov_s@rad.com Mon Oct 19 06:52:15 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A41A628C120; Mon, 19 Oct 2009 06:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gREL7BhaMd47; Mon, 19 Oct 2009 06:52:13 -0700 (PDT) Received: from antivir2.rad.co.il (antivir2.rad.co.il [62.0.23.221]) by core3.amsl.com (Postfix) with ESMTP id 1537F3A6856; Mon, 19 Oct 2009 06:52:10 -0700 (PDT) Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by antivir2.rad.co.il with ESMTP; 19 Oct 2009 15:51:56 +0200 Received: from exrad4.ad.rad.co.il ([192.114.24.47]) by exrad4.ad.rad.co.il ([192.114.24.47]) with mapi; Mon, 19 Oct 2009 15:51:55 +0200 From: Yaakov Stein To: "mpls-tp@ietf.org" Date: Mon, 19 Oct 2009 15:51:51 +0200 Thread-Topic: Re: poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft Thread-Index: AcpQw09zu7QokPAtSQ6f+YqfhJBh5A== Message-ID: <48E7911F78327A449A9FB956376672862B104DAA@exrad4.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_48E7911F78327A449A9FB956376672862B104DAAexrad4adradcoil_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 19 Oct 2009 14:35:23 -0700 Cc: "ccamp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 13:52:15 -0000 --_000_48E7911F78327A449A9FB956376672862B104DAAexrad4adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Although there are some glaring errors. For example, for packet loss and delay there is a statement There is no mechanism defined in the IETF to support this function. I think the authors should look at the RFCs produced by IPPM, and in fact I think that OWAMP and/or TWAMP could be considered as an alter= native to Y.1731 mechanisms. Y(J)S --_000_48E7911F78327A449A9FB956376672862B104DAAexrad4adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

Although there are some glaring errors.

For example, for packet loss and delay there is a stat= ement

   There is no mechanism defined in the IETF= to support this function.

 

I think the authors should look at the RFCs produced b= y IPPM,

and in fact I think that OWAMP and/or TWAMP could be considered as an alternative to Y.1731 mechanisms.

 

Y(J)S

 

--_000_48E7911F78327A449A9FB956376672862B104DAAexrad4adradcoil_-- From adrian@olddog.co.uk Mon Oct 19 15:21:22 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 592213A6991 for ; Mon, 19 Oct 2009 15:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.625 X-Spam-Level: X-Spam-Status: No, score=-1.625 tagged_above=-999 required=5 tests=[AWL=0.973, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p1IXri2QtA7 for ; Mon, 19 Oct 2009 15:21:21 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.193.159]) by core3.amsl.com (Postfix) with ESMTP id BFD6A3A67B6 for ; Mon, 19 Oct 2009 15:21:11 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id n9JML4bm017257; Mon, 19 Oct 2009 23:21:09 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id n9JML3o0017250; Mon, 19 Oct 2009 23:21:03 +0100 Message-ID: From: "Adrian Farrel" To: "Attila Takacs \(IJ/ETH\)" , Date: Mon, 19 Oct 2009 23:06:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: ccamp@ietf.org Subject: [CCAMP] Fw: I-D Action:draft-kern-ccamp-rsvpte-hop-attributes-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 22:21:22 -0000 Hi, Did you notice that RFC 5420 allows the recording of per attributes in the RRO using the RRO Attributes Subobject as defined in section 7.2? I would suggest you should not define a duplicate of this function, and if you need similar function in the ERO you should use the same subobject type and number. The RRO Attributes Subobject collects only flags (not TLVs). This was a deliberate decision based on scalability and there being no defined requirements for collecting TLVs. Similarly, we did not define an ERO Attributes Subobject, because there was no defined requirement to have an LSP behave differently on different hops. I think that it might be useful if you could set out your requirements before extending the protocol in this way. Cheers, Adrian ----- Original Message ----- From: To: Sent: Monday, October 19, 2009 4:45 PM Subject: I-D Action:draft-kern-ccamp-rsvpte-hop-attributes-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Encoding of Attributes of LSP intermediate hops using > RSVP-TE > Author(s) : A. Kern, A. Takacs > Filename : draft-kern-ccamp-rsvpte-hop-attributes-00.txt > Pages : 10 > Date : 2009-10-19 > > RFC5420 specifies a general framework to support signaling and > reporting of generic attributes relevant for a signaled LSP. This > document extends the concept and defines a new Explicit Route > subobject for RSVP-TE to allow the specification and reporting of > attributes relevant to a particular hop of the signaled LSP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kern-ccamp-rsvpte-hop-attributes-00.txt From Adrian.Farrel@huawei.com Mon Oct 19 15:51:02 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D96B428C124; Mon, 19 Oct 2009 15:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.152 X-Spam-Level: X-Spam-Status: No, score=-1.152 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_05=-1.11, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7A8QQ5XnmhW1; Mon, 19 Oct 2009 15:51:02 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 2AC163A6914; Mon, 19 Oct 2009 15:51:02 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRS005O4A565V@usaga03-in.huawei.com>; Mon, 19 Oct 2009 17:51:06 -0500 (CDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRS005B4A53HN@usaga03-in.huawei.com>; Mon, 19 Oct 2009 17:51:06 -0500 (CDT) Date: Mon, 19 Oct 2009 23:49:50 +0100 From: Adrian Farrel To: ason-routing@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Cc: ccamp-chairs@tools.ietf.org, ccamp@ietf.org, Jonathan Sadler , Ross Callon Subject: [CCAMP] Closure of the ASON Routing List and the Associated Design Team X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 22:51:03 -0000 Hi, The work of the ASON Design Team seems to have stalled with no progress for a long time, and no discussion on this list. Accordingly, I am shutting the team and closing the mailing list. The mailing list archive will remain available. For info, here is the liaison we sent to the ITU-T on the subject. https://datatracker.ietf.org/liaison/566/ Of course, the topic remains available for discussion on the ccamp list. Thanks, Adrian From ylee@huawei.com Mon Oct 19 15:54:14 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306B728C188; Mon, 19 Oct 2009 15:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ah24ziOPdwcW; Mon, 19 Oct 2009 15:54:11 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 70C1D3A6914; Mon, 19 Oct 2009 15:54:11 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRS00DN2AAHMK@usaga04-in.huawei.com>; Mon, 19 Oct 2009 17:54:18 -0500 (CDT) Received: from L73682 ([10.124.12.76]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRS002ZXAABDD@usaga04-in.huawei.com>; Mon, 19 Oct 2009 17:54:17 -0500 (CDT) Date: Mon, 19 Oct 2009 17:54:11 -0500 From: Young Lee To: 'CCAMP' , pce@ietf.org Message-id: <000f01ca510f$13f91250$4c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_nZJ26SsYEn3t3l3mgy0HXg)" Thread-index: AcpRDxJELzyTSoABToKuuzhRCpXYHg== Subject: [CCAMP] signal compatibility drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 22:54:14 -0000 This is a multi-part message in MIME format. --Boundary_(ID_nZJ26SsYEn3t3l3mgy0HXg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, We have recently uploaded WSON signal compatibility related drafts in both CCAMP and PCE WG's. Here are the three sets of drafts that address signal compatibility and processing constraints in WSON. http://tools.ietf.org/id/draft-bernstein-ccamp-wson-compatibility-01.txt (Framework) http://tools.ietf.org/id/draft-lee-ccamp-wson-signal-compatibility-ospf-00.t xt (OSPF extensions) http://tools.ietf.org/id/draft-lee-pce-wson-signal-compatibility-00.txt (PCEP extensions) We'd appreciate your interest and comments for these drafts. Thanks. Young --Boundary_(ID_nZJ26SsYEn3t3l3mgy0HXg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi, =

 

We have recently uploaded WSON signal compatibility = related drafts in both CCAMP and PCE WG’s. Here are the three sets of = drafts that address signal compatibility and processing constraints in WSON. =

 

http://tools.ietf.org/id/draft-bernstein-ccamp-wson-compatibilit= y-01.txt (Framework)

http://tools.ietf.org/id/draft-lee-ccamp-wson-signal-compa= tibility-ospf-00.txt (OSPF extensions)

http://tools.ietf.org/id/draft-lee-pce-wson-signal-compatibility-= 00.txt (PCEP extensions)

 

We’d appreciate your interest and comments for = these drafts. Thanks.

 

Young

--Boundary_(ID_nZJ26SsYEn3t3l3mgy0HXg)-- From daniel@olddog.co.uk Tue Oct 20 02:48:11 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF8D33A6875 for ; Tue, 20 Oct 2009 02:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJowiOpCD6hW for ; Tue, 20 Oct 2009 02:48:11 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id B86033A6801 for ; Tue, 20 Oct 2009 02:48:10 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n9K9m2gB010433; Tue, 20 Oct 2009 10:48:02 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n9K9m1Rk010413; Tue, 20 Oct 2009 10:48:01 +0100 From: "Daniel King" To: Date: Tue, 20 Oct 2009 10:48:03 +0100 Message-ID: <002301ca516a$6b2301c0$41690540$@co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01CA5172.CCE769C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcpRamqNNyGE44MrRaWJ1YH8lBbJuA== Content-Language: en-gb Subject: [CCAMP] Agenda Requests for IETF 76 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 09:48:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0024_01CA5172.CCE769C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Konichiwa, Our CCAMP sessions are currently scheduled for: Session 1 13:00-15:00 on Wednesday, November 11. Session 2 09:00-11:30 on Thursday, November 12. If you have an agenda request, please let me know by October 28. Please note, the agenda priority will be draft updates and new submissions. Br, Dan. ------=_NextPart_000_0024_01CA5172.CCE769C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Konichiwa,

 

Our CCAMP sessions are currently scheduled = for:

 

Session 1

13:00-15:00 on Wednesday, November 11.  =

 

Session 2

09:00-11:30 on Thursday, November = 12.

 

If you have an agenda request, please let me know = by October 28. Please note, the agenda priority will be draft updates and new = submissions.

 

Br, Dan.

------=_NextPart_000_0024_01CA5172.CCE769C0-- From stbryant@cisco.com Tue Oct 20 02:51:21 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64DC3A6875; Tue, 20 Oct 2009 02:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.776 X-Spam-Level: X-Spam-Status: No, score=-10.776 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqqDDrx9BJUv; Tue, 20 Oct 2009 02:51:20 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D57513A67E1; Tue, 20 Oct 2009 02:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=6974; q=dns/txt; s=amsiport01001; t=1256032288; x=1257241888; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Stewart=20Bryant=20 |Reply-To:=20stbryant@cisco.com|Subject:=20Re:=20[PWE3] =20[CCAMP]=20poll=20on=20making=20draft-sprecher-mpls-tp- oam-analysis-07.txt=0D=0A=20a=20working=20group=20draft |Date:=20Tue,=2020=20Oct=202009=2010:51:18=20+0100 |Message-ID:=20<4ADD8816.8050807@cisco.com>|To:=20"Sadler ,=20Jonathan=20B."=20|CC:=20 "Thomas=20D.=20Nadeau"=20,=20Loa=20And ersson=20,=0D=0A=20=20=20=20=20=20=20=20"mpls- tp@ietf.org"=20,=20"pwe3@ietf.org"=20

,=0D=0A=20=20=20=20=20=20=20=20"ccamp@ietf.o rg"=20|MIME-Version:=201.0|In-Reply-To: =20<5292FFA96EC22A4386067E9DBCC0CD2B5DE5591C1F@EX-NAP.tel labs-west.tellabsinc.net>|References:=20<4ADB550F.8080507 @pi.nu>,=20<5292FFA96EC 22A4386067E9DBCC0CD2B5DE5591C1F@EX-NAP.tellabs-west.tella bsinc.net>; bh=FejzWfn3V9FAICZT8w1P5QYGsEbBadX1p32YitIGNuU=; b=RmVVP8Vou1tqQ6ydFLiyKtUkBX/oozmHKW9Hdc2bTO3/GTVSsHBibTvl xbHDiDyyW+h07SDvEiAv9r9HzY4SjagUa5StAnW+Z4jLfsxF4w1mFjgJk G24uDCZOqZ9xyQYkf8TMIVl31H9HVk3HkR/2Nddb0NAoDjaUfM+tQDbY2 o=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEAAOMk3UqQ/uCWe2dsb2JhbACCJDAlmCMBARYkBqU+gRkIAZZ0hDEEgVw X-IronPort-AV: E=Sophos;i="4.44,590,1249257600"; d="scan'208,217";a="52226098" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2009 09:51:19 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9K9pJXk029760; Tue, 20 Oct 2009 09:51:19 GMT Received: from dhcp-gpk02-vlan300-64-103-65-125.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id n9K9pID20679; Tue, 20 Oct 2009 10:51:18 +0100 (BST) Message-ID: <4ADD8816.8050807@cisco.com> Date: Tue, 20 Oct 2009 10:51:18 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Sadler, Jonathan B." References: <4ADB550F.8080507@pi.nu>, <5292FFA96EC22A4386067E9DBCC0CD2B5DE5591C1F@EX-NAP.tellabs-west.tellabsinc.net> In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2B5DE5591C1F@EX-NAP.tellabs-west.tellabsinc.net> Content-Type: multipart/alternative; boundary="------------090804010800010908050504" Cc: "ccamp@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [PWE3] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 09:51:22 -0000 This is a multi-part message in MIME format. --------------090804010800010908050504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I disagree. I believe that it is useful to document the OAM design decision and that this document is a good starting point. Remember that the poll is not whether to publish this document at any particular time, but to accept it as a starting point for the work of the WG. As such I think the document is useful, and a good staring point, which is why I expressed the view that it should become a WG doc. Stewart Sadler, Jonathan B. wrote: > I agree with Tom that this document seems to be more of a set of meeting minutes/notes. I don't see any reasoned analysis - just a statement of what is different between the two mechanisms and the requirements along with a recommendation. > > The fact no discussion of inter-layer interactions is shown in this document really concerns me as I believe its missing a key difference between the approaches catalogued. > > If the document contained reasoned analysis and delt with all issues, I would be able to support it. But in its current form it is lacking the required substance. > > Jonathan Sadler > > ________________________________________ > From: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] On Behalf Of Thomas D. Nadeau [tom.nadeau@bt.com] > Sent: Sunday, October 18, 2009 7:27 PM > To: Loa Andersson; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: Re: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft > > As I said earlier, I do not see the point in bringing this document > forward. I viewed it more as a set of meeting minutes/notes that were held > by the MEAD team, and as such has served its purpose. > > --Tom > > > > On 10/18/09 1:49 PM, "Loa Andersson" wrote: > > >> Working Group, >> >> the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have >> asked that the draft is adopted as an mpls working group document. >> >> This mail starts a two week poll on making the draft a working group >> document. Send a mail to the mpls-tp@ietf.org mailing list, indicating >> "yes/support" or "no/do not support". >> >> Comments on the content should be sent to the same mailing list with >> a different subject line. >> >> The poll ends Fri Oct 30. >> >> Loa and George >> MPLS working group co-chairs >> > > -- > Principal Architect - 21CN Networks > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > --------------090804010800010908050504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I disagree. I believe that it is useful to document the OAM design
decision and that this document is a good starting point.

Remember that the poll is not whether to publish this document
at any particular time, but to accept it as a starting point for
the work of the WG.

As such I think the document is useful, and a good staring point,
which is why I expressed the view that it should become a WG doc.

Stewart



Sadler, Jonathan B. wrote: 

I agree with Tom that this document seems to be more of a set of meeting minutes/notes.  I don't see any reasoned analysis - just a statement of what is different between the two mechanisms and the requirements along with a recommendation.

The fact no discussion of inter-layer interactions is shown in this document really concerns me as I believe its missing a key difference between the approaches catalogued.

If the document contained reasoned analysis and delt with all issues, I would be able to support it.  But in its current form it is lacking the required substance.

Jonathan Sadler

________________________________________
From: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] On Behalf Of Thomas D. Nadeau [tom.nadeau@bt.com]
Sent: Sunday, October 18, 2009 7:27 PM
To: Loa Andersson; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org
Subject: Re: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft

    As I said earlier, I do not see the point in bringing this document
forward. I viewed it more as a set of meeting minutes/notes that were held
by the MEAD team, and as such has served its purpose.

    --Tom



On 10/18/09 1:49 PM, "Loa Andersson" <loa@pi.nu> wrote:

  
Working Group,

the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have
asked that the draft is adopted as an mpls working group document.

This mail starts a two week poll on making the draft a working group
document. Send a mail to the mpls-tp@ietf.org mailing list, indicating
"yes/support" or "no/do not support".

Comments on the content should be sent to the same mailing list with
a different subject line.

The poll ends Fri Oct 30.

Loa and George
MPLS working group co-chairs
    

--
Principal Architect - 21CN Networks


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

--------------090804010800010908050504-- From lberger@labn.net Tue Oct 20 03:55:25 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0253A6822 for ; Tue, 20 Oct 2009 03:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.087 X-Spam-Level: X-Spam-Status: No, score=-1.087 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3Exc87jtzUX for ; Tue, 20 Oct 2009 03:55:24 -0700 (PDT) Received: from outbound-mail-09.bluehost.com (outbound-mail-09.bluehost.com [69.89.17.209]) by core3.amsl.com (Postfix) with SMTP id C102D3A6784 for ; Tue, 20 Oct 2009 03:55:24 -0700 (PDT) Received: (qmail 1216 invoked by uid 0); 20 Oct 2009 10:55:32 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy1.bluehost.com with SMTP; 20 Oct 2009 10:55:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=wJwQAkOa/WA/4GD8rFEkI/MYSW+Ffja4qQYo15UdKjRA8dmrCNFn1GZODyUbZ6SqQwwmOhj4DwZuqssGUAwFGsRbuFBy6GNAa+pokUte8uWVokUt4JUS0sbbQ6BeFByI; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N0CNI-0007WS-9R; Tue, 20 Oct 2009 04:55:32 -0600 Message-ID: <4ADD9734.9090308@labn.net> Date: Tue, 20 Oct 2009 06:55:48 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: CCAMP WG References: <002301ca516a$6b2301c0$41690540$@co.uk> In-Reply-To: <002301ca516a$6b2301c0$41690540$@co.uk> X-Enigmail-Version: 0.96a 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] Agenda Requests for IETF 76 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 10:55:25 -0000 All, Please also include the chairs in your agenda requests. (In addition to Dan, the WG secretary.) Lou PS Yes, we have already received a number of requests. On 10/20/2009 5:48 AM, Daniel King wrote: > > If you have an agenda request, please let me know by October 28. Please > note, the agenda priority will be draft updates and new submissions. > From tom.nadeau@bt.com Tue Oct 20 05:07:16 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2025B3A6914; Tue, 20 Oct 2009 05:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp7xGW+iBZcY; Tue, 20 Oct 2009 05:07:09 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 457813A68F3; Tue, 20 Oct 2009 05:07:08 -0700 (PDT) Received: from E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.103]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 13:07:15 +0100 Received: from 217.32.164.181 ([217.32.164.181]) by E03MVA4-UKBR.domain1.systemhost.net ([193.113.197.56]) via Exchange Front-End Server mail.bt.com ([193.113.197.150]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Oct 2009 12:07:15 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Tue, 20 Oct 2009 08:07:13 -0400 From: "Thomas D. Nadeau" To: Stewart Bryant , "Sadler, Jonathan B." Message-ID: Thread-Topic: [PWE3] [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft Thread-Index: AcpRfduRTcXXzzlL+UWpSmfFx/h1ew== In-Reply-To: <4ADD8816.8050807@cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3338870834_31513193" X-OriginalArrivalTime: 20 Oct 2009 12:07:15.0762 (UTC) FILETIME=[DD372120:01CA517D] Cc: "ccamp@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [PWE3] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 12:07:16 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3338870834_31513193 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable On 10/20/09 5:51 AM, "Stewart Bryant" wrote: > I disagree. I believe that it is useful to document the OAM design > decision and that this document is a good starting point. >=20 > TOM: I do not think anyone was saying it was useless per se. The issue i= s > whether or not it is useful in its current state as a WG document, or eve= n as > a starting point and being modified later. The document currently reads = as a > mish-mash of notes on OAM techniques, which surely cannot be a useful sta= rting > point. As a starting point, I=B9d say it could become a survey on OAM > techniques going forward, but I=B9d ask the WG if it is a) unavailable else= where > in another form and b) if its truly worth spending the WG=B9s editorial and > charter resources on? >=20 > --Tom >=20 >=20 >=20 > Remember that the poll is not whether to publish this document > at any particular time, but to accept it as a starting point for > the work of the WG. >=20 > As such I think the document is useful, and a good staring point, > which is why I expressed the view that it should become a WG doc. >=20 > Stewart >=20 >=20 >=20 > Sadler, Jonathan B. wrote: >> =20 >> I agree with Tom that this document seems to be more of a set of meeting >> minutes/notes. I don't see any reasoned analysis - just a statement of = what >> is different between the two mechanisms and the requirements along with = a >> recommendation. >>=20 >> The fact no discussion of inter-layer interactions is shown in this docu= ment >> really concerns me as I believe its missing a key difference between the >> approaches catalogued. >>=20 >> If the document contained reasoned analysis and delt with all issues, I = would >> be able to support it. But in its current form it is lacking the requir= ed >> substance. >>=20 >> Jonathan Sadler >>=20 >> ________________________________________ >> From: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] On Behalf Of Thoma= s D. >> Nadeau [tom.nadeau@bt.com] >> Sent: Sunday, October 18, 2009 7:27 PM >> To: Loa Andersson; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org >> Subject: Re: [CCAMP] poll on making >> draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft >>=20 >> As I said earlier, I do not see the point in bringing this document >> forward. I viewed it more as a set of meeting minutes/notes that were he= ld >> by the MEAD team, and as such has served its purpose. >>=20 >> --Tom >>=20 >>=20 >>=20 >> On 10/18/09 1:49 PM, "Loa Andersson" wro= te: >>=20 >> =20 >> =20 >>> =20 >>> Working Group, >>>=20 >>> the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have >>> asked that the draft is adopted as an mpls working group document. >>>=20 >>> This mail starts a two week poll on making the draft a working group >>> document. Send a mail to the mpls-tp@ietf.org mailing list, indicating >>> "yes/support" or "no/do not support". >>>=20 >>> Comments on the content should be sent to the same mailing list with >>> a different subject line. >>>=20 >>> The poll ends Fri Oct 30. >>>=20 >>> Loa and George >>> MPLS working group co-chairs >>> =20 >>> =20 >> =20 >>=20 >> -- >> Principal Architect - 21CN Networks >>=20 >>=20 >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >>=20 >> =20 >=20 >=20 --=20 Principal Architect - 21CN Networks --B_3338870834_31513193 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [PWE3] [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysi= s-07.txt a working group draft


On 10/20/09 5:51 AM, "Stewart Bryant" <stbryant@cisco.com> wrote:

<= SPAN STYLE=3D'font-size:13pt'>I disagree. I believe that it is useful to docum= ent the OAM design
decision and that this document is a good starting point.

TOM: I do not think anyone was saying it was useless per se.  The issu= e is whether or not it is useful in its current state as a WG document, or e= ven as a starting point and being modified later.  The document current= ly reads as a mish-mash of notes on OAM techniques, which surely cannot be a= useful starting point.  As a starting point, I’d say it could be= come a survey on OAM techniques going forward, but I’d ask the WG if i= t is a) unavailable elsewhere in another form and b) if its truly worth spen= ding the WG’s editorial and charter resources on?

    --Tom



Remember that the poll is not whether to publish this document
at any particular time, but to accept it as a starting point for
the work of the WG.

As such I think the document is useful, and a good staring point,
which is why I expressed the view that it should become a WG doc.

Stewart



Sadler, Jonathan B. wrote:
<= SPAN STYLE=3D'font-size:13pt'>
I agree with Tom that this document seems to be more of a set of meeting mi= nutes/notes.  I don't see any reasoned analysis - just a statement of w= hat is different between the two mechanisms and the requirements along with = a recommendation.

The fact no discussion of inter-layer interactions is shown in this documen= t really concerns me as I believe its missing a key difference between the a= pproaches catalogued.

If the document contained reasoned analysis and delt with all issues, I wou= ld be able to support it.  But in its current form it is lacking the re= quired substance.

Jonathan Sadler

________________________________________
From: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] On Behalf Of Thomas D. = Nadeau [tom.nadeau@bt.com]
Sent: Sunday, October 18, 2009 7:27 PM
To: Loa Andersson; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org<= /a>
Subject: Re: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.= txt a working group draft

    As I said earlier, I do not see the point in bringi= ng this document
forward. I viewed it more as a set of meeting minutes/notes that were held<= BR> by the MEAD team, and as such has served its purpose.

    --Tom



On 10/18/09 1:49 PM, "Loa Andersson" <loa@= pi.nu> <mailto:loa@pi.nu>  = wrote:

  
 
<= SPAN STYLE=3D'font-size:13pt'>
Working Group,

the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have
asked that the draft is adopted as an mpls working group document.

This mail starts a two week poll on making the draft a working group
document. Send a mail to the mpls-tp@ietf.org mailing list, indicating
"yes/support" or "no/do not support".

Comments on the content should be sent to the same mailing list with
a different subject line.

The poll ends Fri Oct 30.

Loa and George
MPLS working group co-chairs
    
 
=

--
Principal Architect - 21CN Networks


_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/= mailman/listinfo/ccamp
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/m= ailman/listinfo/pwe3

  
=

=
--
Principal Architect - 21CN Networks

 --B_3338870834_31513193-- From andras.kern@ericsson.com Tue Oct 20 06:27:02 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 503E53A69D8 for ; Tue, 20 Oct 2009 06:27:02 -0700 (PDT) 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=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TID00U9V6g5G for ; Tue, 20 Oct 2009 06:27:01 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id EFA603A69AA for ; Tue, 20 Oct 2009 06:27:00 -0700 (PDT) X-AuditID: c1b4fb24-b7bd7ae000002270-de-4addbaaacff8 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id FC.49.08816.AAABDDA4; Tue, 20 Oct 2009 15:27:07 +0200 (CEST) Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Oct 2009 15:25:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Oct 2009 15:25:55 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-kern-ccamp-rsvpte-hop-attributes-00.txt thread-index: AcpRCnqdgUlw73AxQgmi8xqPrxYOKwAfYXNA References: From: =?iso-8859-1?Q?Andr=E1s_Kern?= To: "Adrian Farrel" , "Attila Takacs" X-OriginalArrivalTime: 20 Oct 2009 13:25:57.0091 (UTC) FILETIME=[DB58C330:01CA5188] X-Brightmail-Tracker: AAAAAA== Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action:draft-kern-ccamp-rsvpte-hop-attributes-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 13:27:02 -0000 Hi Adrian, The considered use case is to enable configuring non-intrusive and/or=20 tandem connection monitoring entities for OTN networks: to carry=20 endpoint identification and monitoring parameter encoding structures.=20 The update of draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext (should be = uploaded by next Monday) will make use of the new ERO subobject. =20 This placeholder (HOP_ATTRIBUTES subobject) may be useful in other=20 cases as well, like for instance WSON. That is why it has been=20 submitted as a separated document. =20 As an alternative I have considered using the LSP_REQUIRED_ATTRIBUTES,=20 but in that case there may be a mismatch between the hops encoded in=20 the LSP_REQUIRED_ATTRIBUTES and the hops that will be actually used,=20 i.e., the ones specified in the ERO. =20 The scope of the RRO_ATTRIBUTES is different, it encodes LSP related = attributes, these will likely be different form the the hop related = attributes. That is why a new subobject is proposed. However, curently I = do not see a clear use case for HOP ATTRIBUTES in the RRO. So merging = with RRO_ATTRIBUTES may be possible. =20 Best Regards Andras=20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 > Sent: Tuesday, October 20, 2009 12:06 AM > To: Attila Takacs; Andr=E1s Kern > Cc: ccamp@ietf.org > Subject: Fw: I-D Action:draft-kern-ccamp-rsvpte-hop-attributes-00.txt=20 >=20 > Hi, >=20 > Did you notice that RFC 5420 allows the recording of per=20 > attributes in the RRO using the RRO Attributes Subobject as=20 > defined in section 7.2? >=20 > I would suggest you should not define a duplicate of this=20 > function, and if you need similar function in the ERO you=20 > should use the same subobject type and number. >=20 > The RRO Attributes Subobject collects only flags (not TLVs).=20 > This was a deliberate decision based on scalability and there=20 > being no defined requirements for collecting TLVs. >=20 > Similarly, we did not define an ERO Attributes Subobject,=20 > because there was no defined requirement to have an LSP=20 > behave differently on different hops. >=20 > I think that it might be useful if you could set out your=20 > requirements before extending the protocol in this way. >=20 > Cheers, > Adrian >=20 > ----- Original Message ----- > From: > To: > Sent: Monday, October 19, 2009 4:45 PM > Subject: I-D Action:draft-kern-ccamp-rsvpte-hop-attributes-00.txt >=20 >=20 > >A New Internet-Draft is available from the on-line Internet-Drafts=20 > >directories. > > > > Title : Encoding of Attributes of LSP=20 > intermediate hops using=20 > > RSVP-TE > > Author(s) : A. Kern, A. Takacs > > Filename : draft-kern-ccamp-rsvpte-hop-attributes-00.txt > > Pages : 10 > > Date : 2009-10-19 > > > > RFC5420 specifies a general framework to support signaling and > > reporting of generic attributes relevant for a signaled LSP. This > > document extends the concept and defines a new Explicit Route > > subobject for RSVP-TE to allow the specification and reporting of > > attributes relevant to a particular hop of the signaled LSP. > > > > A URL for this Internet-Draft is: > >=20 > http://www.ietf.org/internet-drafts/draft-kern-ccamp-rsvpte-ho > p-attributes-00.txt >=20 >=20 From lberger@labn.net Tue Oct 20 15:02:30 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679433A67E5 for ; Tue, 20 Oct 2009 15:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7+-jzAYW60l for ; Tue, 20 Oct 2009 15:02:29 -0700 (PDT) Received: from outbound-mail-149.bluehost.com (outbound-mail-149.bluehost.com [67.222.38.39]) by core3.amsl.com (Postfix) with SMTP id 8FC603A67B1 for ; Tue, 20 Oct 2009 15:02:26 -0700 (PDT) Received: (qmail 13007 invoked by uid 0); 20 Oct 2009 22:02:34 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy5.bluehost.com with SMTP; 20 Oct 2009 22:02:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=1lYoLDajo6Xch9tZ4uNghUTiplXjwUb7jRNMTvUoWoWm1Jb5s/YZgSNPt2lgHEOpbwIbG4wN0hDKPkWCAXUKH/8Bioq60FK4JsaLuNdhMux7K6sOxdcEjRpo4uoGR+Mw; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N0Mmo-0004O1-HO; Tue, 20 Oct 2009 16:02:34 -0600 Message-ID: <4ADE338B.5030104@labn.net> Date: Tue, 20 Oct 2009 18:02:51 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: draft-ietf-ccamp-rwa-wson-framework@tools.ietf.org X-Enigmail-Version: 0.96a 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 WG Subject: [CCAMP] A general question on the WSON Framework draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 22:02:30 -0000 Authors, (WG) I have a pretty basic question on the WSON framework document: What is the scope of the optical networks covered by this framework? I think the document should be very clear on this. Keep in mind that a framework (or even protocol) may allow for, i.e., not preclude, functions and aspects of an architecture or solution without fully defining them. To elaborate on my question: A) It's clear that some portions of optical networks are in scope, such as: "wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters". But it is unclear if other portions are in or out; in particular regenerators, OEO switches and, to some degree, OXCs. All are mentioned in the document, but the document is a bit vague on whether they are part of the framework or not. So what's included and what's excluded? My personal opinion is that the framework should allow for all aspects of today's optical networks, but need not define support for each (e.g., impairment based RWA). B) Are multiple signal types included or not? The document seems to say that they are not, but then there is section 3.2.2. It seems to me that it really doesn't take much to allow for support of multiple signal types in this document. Given that multiple signal types are a reality in today's optical networks, I personally think they belong in the framework. I have a bunch of more minor comments on the document, but will hold these until the above is closed. Much thanks, Lou From ylee@huawei.com Tue Oct 20 16:14:33 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D1A3A687E for ; Tue, 20 Oct 2009 16:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDHSN2ilA+EW for ; Tue, 20 Oct 2009 16:14:32 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id D60F43A67B6 for ; Tue, 20 Oct 2009 16:14:32 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU00KAX5WFKH@usaga02-in.huawei.com> for ccamp@ietf.org; Tue, 20 Oct 2009 16:14:40 -0700 (PDT) Received: from L73682 ([10.124.12.76]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRU00AHC5WB17@usaga02-in.huawei.com> for ccamp@ietf.org; Tue, 20 Oct 2009 16:14:39 -0700 (PDT) Date: Tue, 20 Oct 2009 18:14:35 -0500 From: Young Lee In-reply-to: <4ADE338B.5030104@labn.net> To: 'Lou Berger' , draft-ietf-ccamp-rwa-wson-framework@tools.ietf.org Message-id: <009401ca51db$17146260$4c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcpR0T5g9UVz77lPTMOcnPhFFZaa0gAB+nRg References: <4ADE338B.5030104@labn.net> Cc: 'CCAMP WG' Subject: Re: [CCAMP] A general question on the WSON Framework draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 23:14:33 -0000 Hi Lou, Thanks for your comments. Please see in-line for my response. In a nutshell, what the authors' intention of the WSON Framework was to stay in the basic RWA issues (including Wavelength Converters and OXC); Having said that, any multi-signal related issues (we refer to this as signal compatibility and processing constraints) that encompass Regenerators and OEO switches is addressed in a separate document we just updated. Impairment has been addressed separately as you know. Perhaps, Greg can elaborate more from his perspective. Regards, Young -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Tuesday, October 20, 2009 5:03 PM To: draft-ietf-ccamp-rwa-wson-framework@tools.ietf.org Cc: CCAMP WG Subject: A general question on the WSON Framework draft Authors, (WG) I have a pretty basic question on the WSON framework document: What is the scope of the optical networks covered by this framework? I think the document should be very clear on this. Keep in mind that a framework (or even protocol) may allow for, i.e., not preclude, functions and aspects of an architecture or solution without fully defining them. To elaborate on my question: A) It's clear that some portions of optical networks are in scope, such as: "wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters". But it is unclear if other portions are in or out; in particular regenerators, OEO switches and, to some degree, OXCs. All are mentioned in the document, but the document is a bit vague on whether they are part of the framework or not. So what's included and what's excluded? YOUNG>> WSON RWA Framework includes wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters and OXC. Regenerators and OEO switches are addressed in the context of signal compatibility in a separate document. My personal opinion is that the framework should allow for all aspects of today's optical networks, but need not define support for each (e.g., impairment based RWA). YOUNG>> I agree. The concern we have had was the document gets larger and larger to the point that it is hard to read and edit. In the framework, we added the document relationship across RWA, Impairment and Signal Compatibility so that these are all included in the larger WSON scope than the document is addressing. B) Are multiple signal types included or not? YOUNG>> No. The document seems to say that they are not, but then there is section 3.2.2. It seems to me that it really doesn't take much to allow for support of multiple signal types in this document. Given that multiple signal types are a reality in today's optical networks, I personally think they belong in the framework. YOUNG>> We thought we asked the WG chairs in Stockholm meeting. What we thought we heard was a suggestion to separate "signal issues" from the basic RWA issues. I have a bunch of more minor comments on the document, but will hold these until the above is closed. Much thanks, Lou From lberger@labn.net Tue Oct 20 16:55:53 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D325D3A682E for ; Tue, 20 Oct 2009 16:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ivLm1rU5sBV for ; Tue, 20 Oct 2009 16:55:52 -0700 (PDT) Received: from outbound-mail-23.bluehost.com (outbound-mail-23.bluehost.com [69.89.21.18]) by core3.amsl.com (Postfix) with SMTP id 9EF883A680C for ; Tue, 20 Oct 2009 16:55:52 -0700 (PDT) Received: (qmail 28257 invoked by uid 0); 20 Oct 2009 23:56:00 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy2.bluehost.com with SMTP; 20 Oct 2009 23:56:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=GLYd7tlzneCAwfsf+cy0PLDa/5FGTd4vTvs5RTgAPlCBVySF5VRv6IKv0hzCyO3dXkVTPMj4+npyRliXobxWbv1cHlglUgXTkQp7RQFe7EQ0YOrxc4lkkp6FaGbY9lM9; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N0OYa-0003w6-MX; Tue, 20 Oct 2009 17:56:00 -0600 Message-ID: <4ADE4E21.10207@labn.net> Date: Tue, 20 Oct 2009 19:56:17 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Young Lee References: <4ADE338B.5030104@labn.net> <009401ca51db$17146260$4c0c7c0a@china.huawei.com> In-Reply-To: <009401ca51db$17146260$4c0c7c0a@china.huawei.com> X-Enigmail-Version: 0.96a 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-rwa-wson-framework@tools.ietf.org, 'CCAMP WG' Subject: Re: [CCAMP] A general question on the WSON Framework draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 23:55:53 -0000 Young, Please see below for in-line responses. On 10/20/2009 7:14 PM, Young Lee wrote: > Hi Lou, > > Thanks for your comments. Please see in-line for my response. > > In a nutshell, what the authors' intention of the WSON Framework was to stay > in the basic RWA issues (including Wavelength Converters and OXC); doesn't really leave much out ;-) > > Having said that, any multi-signal related issues (we refer to this as > signal compatibility and processing constraints) that encompass Regenerators > and OEO switches is addressed in a separate document we just updated. > see below. > Impairment has been addressed separately as you know. > Right. This fits with point of a function being allowed for in the framework, but not being fully defined. > Perhaps, Greg can elaborate more from his perspective. > > Regards, > Young > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Tuesday, October 20, 2009 5:03 PM > To: draft-ietf-ccamp-rwa-wson-framework@tools.ietf.org > Cc: CCAMP WG > Subject: A general question on the WSON Framework draft > > Authors, (WG) > > I have a pretty basic question on the WSON framework document: What > is > the scope of the optical networks covered by this framework? > > I think the document should be very clear on this. > > Keep in mind that a framework (or even protocol) may allow for, i.e., > not preclude, functions and aspects of an architecture or solution > without fully defining them. > > To elaborate on my question: > > A) It's clear that some portions of optical networks are in scope, such > as: "wavelength division multiplexed links, tunable laser transmitters, > reconfigurable optical add/drop multiplexers (ROADM) and wavelength > converters". But it is unclear if other portions are in or out; in > particular regenerators, OEO switches and, to some degree, OXCs. All > are mentioned in the document, but the document is a bit vague on > whether they are part of the framework or not. So what's included and > what's excluded? > > YOUNG>> WSON RWA Framework includes wavelength division multiplexed links, > tunable laser transmitters, reconfigurable optical add/drop multiplexers > (ROADM) and wavelength converters and OXC. > > Regenerators and OEO switches are addressed in the context of signal > compatibility in a separate document. > > My personal opinion is that the framework should allow for all aspects > of today's optical networks, but need not define support for each (e.g., > impairment based RWA). > > YOUNG>> I agree. The concern we have had was the document gets larger and > larger to the point that it is hard to read and edit. The flip side of this is that you can end up with such a fragmented document set that the base set isn't really usable (at least in practical terms), and that the base can get significantly out of sync with a critical component. I fear this is where we're ending up with the current work. > In the framework, we > added the document relationship across RWA, Impairment and Signal > Compatibility so that these are all included in the larger WSON scope than > the document is addressing. > right now it reads to me as covering half the relevant problem space, leaving out some very basic (and almost always used) functions. > > B) Are multiple signal types included or not? > > YOUNG>> No. > > The document seems to say that they are not, but then there is section > 3.2.2. It seems to me that it really doesn't take much to allow for > support of multiple signal types in this document. Given that multiple > signal types are a reality in today's optical networks, I personally > think they belong in the framework. > > YOUNG>> We thought we asked the WG chairs in Stockholm meeting. What we > thought we heard was a suggestion to separate "signal issues" from the basic > RWA issues. > I believe we ended this part of the discussion with "let's take it to the list". Albeit a bit delayed, here we are ;-) More seriously, I think there's some concern about defining attributes/functions that are currently not standardized in the ITU-T. I think this is a point that we need to be sensitive to, particularly when considering solutions drafts. But this document is a framework document and, in my personal opinion, the framework should cover (or allow for) all aspects of a typical optical network. Lou > I have a bunch of more minor comments on the document, but will hold > these until the above is closed. > > Much thanks, > Lou > > > > > > From gregb@grotto-networking.com Wed Oct 21 09:51:51 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63BDC28C126 for ; Wed, 21 Oct 2009 09:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVQK-G05YRB4 for ; Wed, 21 Oct 2009 09:51:50 -0700 (PDT) Received: from mail14c40.carrierzone.com (mail14c40.carrierzone.com [209.235.156.154]) by core3.amsl.com (Postfix) with ESMTP id 07FD83A6842 for ; Wed, 21 Oct 2009 09:51:46 -0700 (PDT) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by mail14c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id n9LGps7c028462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Oct 2009 16:51:59 GMT Message-ID: <4ADF3C26.6000901@grotto-networking.com> Date: Wed, 21 Oct 2009 09:51:51 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lou Berger References: <4ADE338B.5030104@labn.net> In-Reply-To: <4ADE338B.5030104@labn.net> Content-Type: multipart/alternative; boundary="------------060809010002040006070103" Cc: draft-ietf-ccamp-rwa-wson-framework@tools.ietf.org, CCAMP WG Subject: Re: [CCAMP] A general question on the WSON Framework draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 16:51:51 -0000 This is a multi-part message in MIME format. --------------060809010002040006070103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Lou, see comments below. This is a key point and one that wasn't clear until we split off the compatibility draft from the framework and had some questions on the list. Regards Greg Lou Berger wrote: > Authors, (WG) > > I have a pretty basic question on the WSON framework document: What is > the scope of the optical networks covered by this framework? > > I think the document should be very clear on this. > > Keep in mind that a framework (or even protocol) may allow for, i.e., > not preclude, functions and aspects of an architecture or solution > without fully defining them. > > To elaborate on my question: > > A) It's clear that some portions of optical networks are in scope, such > as: "wavelength division multiplexed links, tunable laser transmitters, > reconfigurable optical add/drop multiplexers (ROADM) and wavelength > converters". But it is unclear if other portions are in or out; in > particular regenerators, OEO switches and, to some degree, OXCs. All > are mentioned in the document, but the document is a bit vague on > whether they are part of the framework or not. So what's included and > what's excluded? > --> This document extends the GMPLS control plane to include "asymmetric" switches. No matter how they are implemented. It also includes models for shared wavelength converters and detailed link-wavelength usage. Such information is useful across many WSONs. What it doesn't model or cover is signal constraints imposed by particular technology implementations such as an OEO wavelength converter. It also would not be aware of regenerators since it doesn't understand differences among optical signals or impairments. We've moved such text out to the compatibility and impairment drafts. > My personal opinion is that the framework should allow for all aspects > of today's optical networks, but need not define support for each (e.g., > impairment based RWA). > > B) Are multiple signal types included or not? > --> Yes. But no checking of signal compatibility is provided. > The document seems to say that they are not, but then there is section > 3.2.2. It seems to me that it really doesn't take much to allow for > support of multiple signal types in this document. Given that multiple > signal types are a reality in today's optical networks, I personally > think they belong in the framework. > ---> Hmm, we say in the abstract: "nor does it address potential incompatibilities between some types of optical signals and some types of network elements and links" This is a fairly general statement in line with the scope that we intend. But confusingly we say in section 3.2.2: "As pointed out in the introduction, for the purposes of this document we assume that all optical signals used in a WSON are compatible with all links, network elements, and receivers in that WSON." This is too restrictive since it says all signals should be compatible with all links, elements, receivers all over the network. We should probably say something like: As pointed out in the introduction, for the purposes of this document we assume that all optical signals used in a WSON are compatible with /*the*/ links, network elements, and receivers in that WSON */that they traverse or terminate on. /*A "signal" may change its characteristics as it traverses a path, e.g. modulation format, or FEC, particularly at a regeneration point. For this draft we assume that the compatibility of signals and elements has been pre-planned and is not a control plane function to worry about. We split this off as the signal compatibility aspects grew and based on the chairs (Deborah's) comments in Stockholm. See the latest compatibility draft for more complete analysis of the compatibility issues with regenerators, OEOs and the like. > I have a bunch of more minor comments on the document, but will hold > these until the above is closed. > > Much thanks, > Lou > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------060809010002040006070103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Lou, see comments below.  This is a key point and one that wasn't clear until we split off the compatibility draft from the framework and had some questions on the list.

Regards

Greg

Lou Berger wrote: 
Authors, (WG)

	I have a pretty basic question on the WSON framework document:  What is
the scope of the optical networks covered by this framework?

I think the document should be very clear on this.

Keep in mind that a framework (or even protocol) may allow for, i.e.,
not preclude, functions and aspects of an architecture or solution
without fully defining them.

To elaborate on my question:

A) It's clear that some portions of optical networks are in scope, such
as: "wavelength division multiplexed links, tunable laser transmitters,
reconfigurable optical add/drop multiplexers (ROADM) and wavelength
converters". But it is unclear if other portions are in or out; in
particular regenerators, OEO switches and, to some degree, OXCs.  All
are mentioned in the document, but the document is a bit vague on
whether they are part of the framework or not.  So what's included and
what's excluded?
--> This document extends the GMPLS control plane to include "asymmetric" switches. No matter how they are implemented.
It also includes models for shared wavelength converters and detailed link-wavelength usage. Such information is useful across many WSONs.
What it doesn't model or cover is signal constraints imposed by particular technology implementations such as an OEO wavelength converter.
It also would not be aware of regenerators since it doesn't understand differences among optical signals or impairments. We've moved such text out
to the compatibility and impairment drafts.
My personal opinion is that the framework should allow for all aspects
of today's optical networks, but need not define support for each (e.g.,
impairment based RWA).

B) Are multiple signal types included or not?
--> Yes. But no checking of signal compatibility is provided.
The document seems to say that they are not, but then there is section
3.2.2.  It seems to me that it really doesn't take much to allow for
support of multiple signal types in this document.  Given that multiple
signal types are a reality in today's optical networks, I personally
think they belong in the framework.
--->  Hmm, we say in the abstract:
"nor does it address potential incompatibilities between some types of optical signals and some types of network elements and links"
This is a fairly general statement in line with the scope that we intend.

But confusingly we say in section 3.2.2:
"As pointed out in the introduction, for the purposes of this document we assume that all optical signals used in a WSON are compatible with all links, network elements, and receivers in that WSON."

This is too restrictive since it says all signals should be compatible with all links, elements, receivers all over the network. We should probably say something like:
As pointed out in the introduction, for the purposes of this document we assume that all optical signals used in a WSON are compatible with the links, network elements, and receivers in that WSON that they traverse or terminate on.

A "signal" may change its characteristics as it traverses a path, e.g. modulation format, or FEC, particularly at a regeneration point. For this draft we assume that the compatibility of signals and elements has been pre-planned and is not a control plane function to worry about. We split this off as the signal compatibility aspects grew and based on the chairs (Deborah's) comments in Stockholm. See the latest compatibility draft for more complete analysis of the compatibility issues with regenerators, OEOs and the like.
 
I have a bunch of more minor comments on the document, but will hold
these until the above is closed.

Much thanks,
Lou


  

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------060809010002040006070103-- From satoru.matsushima@gmail.com Wed Oct 21 10:11:03 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AA1128C0DF; Wed, 21 Oct 2009 10:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLmsgYlXrixC; Wed, 21 Oct 2009 10:11:02 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 300E03A685C; Wed, 21 Oct 2009 10:10:59 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 9so1002961qwb.31 for ; Wed, 21 Oct 2009 10:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8+1cEBBQzL9QzUVJ0itSNCd8BOmqAIL3Q2ib9ROlbWk=; b=B+gkjEbT4LFat5jb+XVzeutwCdPP/Ewn8Yqm2/6YvNzsS2UNsvhWKBARqD6mSdV+ss P+dnU31iVaWQ8bDoT9lWdNhm6gogR8I77zhkFGS/tL+0onXeY9VrvEQTWFPrB3wvbE9+ F/SqnS/fTlKvzKHDkTrGJdvP7osnpI5MfDUJU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JtKJEpnBTdHb8gDJEDfB4gloky80wVaiT+D/hb7GJNq5O/5fTx/SwhCcqJvnHHSDRM BbD60ZlTl1+70LnBF8Fcvg3s3KQ9OPXmRriMUP+eoZfGTPrEhi0oxMQxJIHTkzchv+yF +c4VJ/vAc85VME1MR5EvyLXznTHjfQN9md8a4= MIME-Version: 1.0 Received: by 10.229.93.4 with SMTP id t4mr1143738qcm.93.1256145065106; Wed, 21 Oct 2009 10:11:05 -0700 (PDT) In-Reply-To: <7D5F2FDD-3C7C-478A-978F-526B827CFF57@cisco.com> References: <4ADB550F.8080507@pi.nu> <5292FFA96EC22A4386067E9DBCC0CD2B5DE5591C1F@EX-NAP.tellabs-west.tellabsinc.net> <4ADD8816.8050807@cisco.com> <7D5F2FDD-3C7C-478A-978F-526B827CFF57@cisco.com> Date: Thu, 22 Oct 2009 02:11:02 +0900 Message-ID: From: Satoru Matsushima To: David Ward Content-Type: text/plain; charset=ISO-8859-1 Cc: "mpls-tp@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" Subject: Re: [CCAMP] [mpls-tp] [PWE3] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 17:11:03 -0000 Hi, > the data could be incorporated into the OAM > architecture draft under construction. I support this. I think that the analysis document is a supplement to make decision, it does not make decision itself. If the analysis document become wg document, I hope to set the date of completion the analysis. -- Satoru Matsushima 2009/10/22 David Ward : > Note that if we decide not to take the document in it's current form > (history of decision making), the data could be incorporated into the OAM > architecture draft under construction. We don't want to lose the > information. > -DWard > On Oct 20, 2009, at 4:51 AM, Stewart Bryant wrote: > > I disagree. I believe that it is useful to document the OAM design > decision and that this document is a good starting point. > > Remember that the poll is not whether to publish this document > at any particular time, but to accept it as a starting point for > the work of the WG. > > As such I think the document is useful, and a good staring point, > which is why I expressed the view that it should become a WG doc. > > Stewart > > > > Sadler, Jonathan B. wrote: > > I agree with Tom that this document seems to be more of a set of meeting > minutes/notes. I don't see any reasoned analysis - just a statement of what > is different between the two mechanisms and the requirements along with a > recommendation. > The fact no discussion of inter-layer interactions is shown in this document > really concerns me as I believe its missing a key difference between the > approaches catalogued. > If the document contained reasoned analysis and delt with all issues, I > would be able to support it. But in its current form it is lacking the > required substance. > Jonathan Sadler > ________________________________________ > From: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] On Behalf Of Thomas D. > Nadeau [tom.nadeau@bt.com] > Sent: Sunday, October 18, 2009 7:27 PM > To: Loa Andersson; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: Re: [CCAMP] poll on making > draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft > As I said earlier, I do not see the point in bringing this document > forward. I viewed it more as a set of meeting minutes/notes that were held > by the MEAD team, and as such has served its purpose. > --Tom > On 10/18/09 1:49 PM, "Loa Andersson" wrote: > > > Working Group, > the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have > asked that the draft is adopted as an mpls working group document. > This mail starts a two week poll on making the draft a working group > document. Send a mail to the mpls-tp@ietf.org mailing list, indicating > "yes/support" or "no/do not support". > Comments on the content should be sent to the same mailing list with > a different subject line. > The poll ends Fri Oct 30. > Loa and George > MPLS working group co-chairs > > > -- > Principal Architect - 21CN Networks > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > From nurit.sprecher@nsn.com Wed Oct 21 10:42:31 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC843A6896 for ; Wed, 21 Oct 2009 10:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAYm5qB1NcKm for ; Wed, 21 Oct 2009 10:42:29 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 5C3163A694C for ; Wed, 21 Oct 2009 10:42:26 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9LHgGXY004293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Oct 2009 19:42:16 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9LHgGkr032089; Wed, 21 Oct 2009 19:42:16 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 19:42:16 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5275.D44A35BF" Date: Wed, 21 Oct 2009 19:42:15 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264016DE8D7@DEMUEXC014.nsn-intra.net> In-Reply-To: <465531011AE4654BA0D30D01AB9EAA6E44A127@FIESEXC030.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt Thread-Index: AcpORZPj/iPwFBMGTue0hbCthsLqfQAAds7AAJnfG/AAH+fu4AAh9iNwACAbJYAACtLMMA== References: <077E41CFFD002C4CAB7DFA4386A532640167C3E9@DEMUEXC014.nsn-intra.net> <465531011AE4654BA0D30D01AB9EAA6E449EB8@FIESEXC030.nsn-intra.net> <328B9F5068825A48A4B8422A350B9047BC9D1E@CNBEEXC006.nsn-intra.net> <077E41CFFD002C4CAB7DFA4386A53264016B2EC2@DEMUEXC014.nsn-intra.net> <465531011AE4654BA0D30D01AB9EAA6E44A127@FIESEXC030.nsn-intra.net> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: , , , X-OriginalArrivalTime: 21 Oct 2009 17:42:16.0582 (UTC) FILETIME=[D4A69A60:01CA5275] Cc: "Soininen, Jonne \(NSN - FI/Espoo\)" , ccamp@ietf.org, "Clemens, Rainer \(NSN - DE/Munich\)" Subject: Re: [CCAMP] I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 17:42:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5275.D44A35BF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Dear authors,=20 =20 Thanks for submitting your document on "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks". =20 We have reviewed the document and we are a little bit concerned to find out that some significant items described in the document are not aligned with what is defined in G.709. =20 Especially the mappings into ODU3e1 and ODU3e2 are only defined in G.Sup43 which is not a standard.=20 In addition G.Sup43 does not define mappings of ODU0, ODU1, ODU2 and ODUflex into ODU3e2. The only mappings that are defined in G.Sup43 are 4x ODU2e. =20 We are afraid that this is not inline with the view of the majority of participants in SG15/Q11. =20 Except of the extensions that are already described in two draft (draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn, draft-zhang-ccamp-gmpls-evolving-g709), all other content of section 3, 4 is copied from ITU standards. Would not it be better to just refer to the ITU-T document? =20 Best regards, Nurit =20 =20 =20 >=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org=20 > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext=20 > Internet-Drafts@ietf.org > Sent: Friday, October 16, 2009 11:45 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Framework for GMPLS and PCE Control=20 > of G.709 Optical Transport Networks > Author(s) : F. Zhang, et al. > Filename : draft-zhang-ccamp-gmpls-g709-framework-00.txt > Pages : 27 > Date : 2009-10-16 >=20 > This document provides a framework for applying Generalized Mulit- > Protocol Label Switching (GMPLS) and the Path Computation Element=20 > (PCE) architecture to the control of G.709 Optical Transport Networks=20 > (OTN) as specified in the ITU-T G.709 recommendation, including the=20 > enhanced functionality in the recently consented revision.=20 >=20 > =20 > =20 > =20 > zhang >=20 >=20 >=20 >=20 >=20 > Expires April 2010 >=20 >=20 >=20 >=20 >=20 > [page 1]=20 >=20 > draft-zhang-ccamp-gmpls-g709-framework-00.txt >=20 >=20 >=20 > October 2009=20 > =20 >=20 > Conventions used in this document=20 >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20 > document are to be interpreted as described in [RFC2119]. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zhang-ccamp-gmpls-g7 > 09-framework-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 ------_=_NextPart_001_01CA5275.D44A35BF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Dear authors,

 

Thanks for submitting your document on "Framework for GMPLS = and PCE Control of G.709 Optical Transport = Networks".

 

We have reviewed the document and we are a little bit concerned = to find out that some significant items described in the document are not = aligned with what is defined in G.709.

 

Especially the mappings into ODU3e1 and = ODU3e2 are only defined in G.Sup43 which is not a standard. =

In addition G.Sup43 does not define mappings = of ODU0, ODU1, ODU2 and ODUflex into ODU3e2. The only mappings that = are defined in G.Sup43 are 4x ODU2e.

 

We are afraid that this is not inline with the view of the = majority of participants in SG15/Q11.

 

Except of the extensions that are already described in two draft (draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn, draft-zhang-ccamp-gmpls-evolving-g709), all other content of section 3, = 4 is copied from ITU standards. Would not it be better to just refer to the = ITU-T document?

 

Best regards,

Nurit

 

 

 

>

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

> From: i-d-announce-bounces@ietf.org =

> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext =

> Internet-Drafts@ietf.org

> Sent: Friday, October 16, 2009 11:45 = AM

> To: i-d-announce@ietf.org

> Subject: I-D = Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt =

>

> A New Internet-Draft is available from the on-line =

> Internet-Drafts directories.

>

>     Title           : = Framework for GMPLS and PCE Control

> of G.709 Optical Transport = Networks

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

>     Filename        : draft-zhang-ccamp-gmpls-g709-framework-00.txt

>     Pages           : = 27

>     Date            : 2009-10-16

>

> This document provides a framework for applying Generalized = Mulit-

> Protocol Label Switching (GMPLS) and the Path Computation = Element

> (PCE) architecture to the control of G.709 Optical = Transport Networks

> (OTN) as specified in the ITU-T G.709 recommendation, = including the

> enhanced functionality in the recently consented revision. =

>

> 

> 

> 

> zhang

>

>

>

>

>

>   Expires April 2010

>

>

>

>

>

>   [page 1]

>

> = draft-zhang-ccamp-gmpls-g709-framework-00.txt

>

>

>

>   October 2009

> 

>

> Conventions used in this document =

>

> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", =

> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this

> document are to be interpreted as described in = [RFC2119].

>

> A URL for this Internet-Draft = is:

> = http://www.ietf.org/internet-drafts/draft-zhang-ccamp-gmpls-g7=

> 09-framework-00.txt

>

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

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

>

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

> implementation to automatically retrieve the ASCII version = of the

> Internet-Draft.

>

------_=_NextPart_001_01CA5275.D44A35BF-- From dward@cisco.com Wed Oct 21 09:53:03 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE78128C101; Wed, 21 Oct 2009 09:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WJPG6MLRl3C; Wed, 21 Oct 2009 09:53:02 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A44693A6842; Wed, 21 Oct 2009 09:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dward@cisco.com; l=8023; q=dns/txt; s=sjiport06001; t=1256143991; x=1257353591; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20David=20Ward=20|Subject:=20Re: =20[PWE3]=20[CCAMP]=20poll=20on=20making=20draft-sprecher -mpls-tp-oam-analysis-07.txt=20a=20working=20group=20draf t|Date:=20Wed,=2021=20Oct=202009=2011:53:10=20-0500 |Message-Id:=20<7D5F2FDD-3C7C-478A-978F-526B827CFF57@cisc o.com>|To:=20stbryant@cisco.com|Cc:=20David=20Ward=20,=0D=0A=20=20=20=20=20=20=20=20"Sadler,=20Jo nathan=20B."=20,=0D=0A=20=20 =20=20=20=20=20=20"ccamp@ietf.org"=20,=0D =0A=20=20=20=20=20=20=20=20"mpls-tp@ietf.org"=20,=20"pwe3@ietf.org"=20 |Mime-Version:=201.0=20(Apple=20Message=20framework=20v10 76)|In-Reply-To:=20<4ADD8816.8050807@cisco.com> |References:=20<4ADB550F.8080507@pi.nu>,=20=20<5292FFA96EC22A4386067E9DBCC0CD2B5 DE5591C1F@EX-NAP.tellabs-west.tellabsinc.net>=20<4ADD8816 .8050807@cisco.com>; bh=bORw6mRef45JGqlELbmIu7awoswiflk0xyiyy/tfPRo=; b=ggvlhMhgmGtk8ErEh9/AWKJsYFiOJSUBYBOpnlqp7EmoinYt3ykeZFNP wFsaaiM9TNo9Z5qpJLyaYiXsp2+V80n3k46+DtML0nLl3yIANco/dujZJ hLWicLXJ9BA1H5x7w9zGxyLMJ91YUDM07iD2oOpIaOINE71gLqG9ce+ZG c=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,598,1249257600"; d="scan'208,217";a="414498115" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 21 Oct 2009 16:53:11 +0000 Received: from [127.0.0.1] (ssh-sjc-2.cisco.com [171.68.46.188]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n9LGrBj1014257; Wed, 21 Oct 2009 16:53:11 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-25-811400007 From: David Ward In-Reply-To: <4ADD8816.8050807@cisco.com> Date: Wed, 21 Oct 2009 11:53:10 -0500 Message-Id: <7D5F2FDD-3C7C-478A-978F-526B827CFF57@cisco.com> References: <4ADB550F.8080507@pi.nu>, <5292FFA96EC22A4386067E9DBCC0CD2B5DE5591C1F@EX-NAP.tellabs-west.tellabsinc.net> <4ADD8816.8050807@cisco.com> To: stbryant@cisco.com X-Mailer: Apple Mail (2.1076) X-Mailman-Approved-At: Wed, 21 Oct 2009 11:50:19 -0700 Cc: "ccamp@ietf.org" , "pwe3@ietf.org" , David Ward , "mpls-tp@ietf.org" Subject: Re: [CCAMP] [PWE3] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 16:53:04 -0000 --Apple-Mail-25-811400007 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Note that if we decide not to take the document in it's current form (history of decision making), the data could be incorporated into the OAM architecture draft under construction. We don't want to lose the information. -DWard On Oct 20, 2009, at 4:51 AM, Stewart Bryant wrote: > I disagree. I believe that it is useful to document the OAM design > decision and that this document is a good starting point. > > Remember that the poll is not whether to publish this document > at any particular time, but to accept it as a starting point for > the work of the WG. > > As such I think the document is useful, and a good staring point, > which is why I expressed the view that it should become a WG doc. > > Stewart > > > > Sadler, Jonathan B. wrote: >> >> I agree with Tom that this document seems to be more of a set of >> meeting minutes/notes. I don't see any reasoned analysis - just a >> statement of what is different between the two mechanisms and the >> requirements along with a recommendation. >> >> The fact no discussion of inter-layer interactions is shown in this >> document really concerns me as I believe its missing a key >> difference between the approaches catalogued. >> >> If the document contained reasoned analysis and delt with all >> issues, I would be able to support it. But in its current form it >> is lacking the required substance. >> >> Jonathan Sadler >> >> ________________________________________ >> From: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] On Behalf Of >> Thomas D. Nadeau [tom.nadeau@bt.com] >> Sent: Sunday, October 18, 2009 7:27 PM >> To: Loa Andersson; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org >> Subject: Re: [CCAMP] poll on making draft-sprecher-mpls-tp-oam- >> analysis-07.txt a working group draft >> >> As I said earlier, I do not see the point in bringing this >> document >> forward. I viewed it more as a set of meeting minutes/notes that >> were held >> by the MEAD team, and as such has served its purpose. >> >> --Tom >> >> >> >> On 10/18/09 1:49 PM, "Loa Andersson" wrote: >> >> >>> Working Group, >>> >>> the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have >>> asked that the draft is adopted as an mpls working group document. >>> >>> This mail starts a two week poll on making the draft a working group >>> document. Send a mail to the mpls-tp@ietf.org mailing list, >>> indicating >>> "yes/support" or "no/do not support". >>> >>> Comments on the content should be sent to the same mailing list with >>> a different subject line. >>> >>> The poll ends Fri Oct 30. >>> >>> Loa and George >>> MPLS working group co-chairs >>> >> >> -- >> Principal Architect - 21CN Networks >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 >> >> > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --Apple-Mail-25-811400007 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Note that if we decide not to take the document in it's current form (history of decision making), the data could be incorporated into the OAM architecture draft under construction. We don't want to lose the information. 

-DWard

On Oct 20, 2009, at 4:51 AM, Stewart Bryant wrote:

I disagree. I believe that it is useful to document the OAM design
decision and that this document is a good starting point.

Remember that the poll is not whether to publish this document
at any particular time, but to accept it as a starting point for
the work of the WG.

As such I think the document is useful, and a good staring point,
which is why I expressed the view that it should become a WG doc.

Stewart



Sadler, Jonathan B. wrote: 
I agree with Tom that this document seems to be more of a set of meeting minutes/notes.  I don't see any reasoned analysis - just a statement of what is different between the two mechanisms and the requirements along with a recommendation.

The fact no discussion of inter-layer interactions is shown in this document really concerns me as I believe its missing a key difference between the approaches catalogued.

If the document contained reasoned analysis and delt with all issues, I would be able to support it.  But in its current form it is lacking the required substance.

Jonathan Sadler

________________________________________
From: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] On Behalf Of Thomas D. Nadeau [tom.nadeau@bt.com]
Sent: Sunday, October 18, 2009 7:27 PM
To: Loa Andersson; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org
Subject: Re: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft

    As I said earlier, I do not see the point in bringing this document
forward. I viewed it more as a set of meeting minutes/notes that were held
by the MEAD team, and as such has served its purpose.

    --Tom



On 10/18/09 1:49 PM, "Loa Andersson" <loa@pi.nu> wrote:

  
Working Group,

the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have
asked that the draft is adopted as an mpls working group document.

This mail starts a two week poll on making the draft a working group
document. Send a mail to the mpls-tp@ietf.org mailing list, indicating
"yes/support" or "no/do not support".

Comments on the content should be sent to the same mailing list with
a different subject line.

The poll ends Fri Oct 30.

Loa and George
MPLS working group co-chairs
    

--
Principal Architect - 21CN Networks


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

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

--Apple-Mail-25-811400007-- From tnadeau@lucidvision.com Wed Oct 21 13:04:10 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE0633A67EC; Wed, 21 Oct 2009 13:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGMjXWCf5fCR; Wed, 21 Oct 2009 13:04:09 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 657323A677E; Wed, 21 Oct 2009 13:04:09 -0700 (PDT) Received: from [10.55.183.139] (unknown [32.151.241.167]) by lucidvision.com (Postfix) with ESMTP id B48AB4179B28; Wed, 21 Oct 2009 16:04:14 -0400 (EDT) References: <4ADB550F.8080507@pi.nu>, <5292FFA96EC22A4386067E9DBCC0CD2B5DE5591C1F@EX-NAP.tellabs-west.tellabsinc.net> <4ADD8816.8050807@cisco.com> <7D5F2FDD-3C7C-478A-978F-526B827CFF57@cisco.com> Message-Id: <2F713EA1-8928-41C3-9628-C879FD9C07BE@lucidvision.com> From: Thomas Nadeau To: David Ward In-Reply-To: <7D5F2FDD-3C7C-478A-978F-526B827CFF57@cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1-822859124 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Wed, 21 Oct 2009 16:04:07 -0400 Cc: "ccamp@ietf.org" , "mpls-tp@ietf.org" , "pwe3@ietf.org" , David Ward Subject: Re: [CCAMP] [PWE3] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 20:04:10 -0000 --Apple-Mail-1-822859124 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I like this idea. On Oct 21, 2009, at 12:53 PM, David Ward wrote: > Note that if we decide not to take the document in it's current form > (history of decision making), the data could be incorporated into > the OAM architecture draft under construction. We don't want to lose > the information. > > -DWard > > On Oct 20, 2009, at 4:51 AM, Stewart Bryant wrote: > >> I disagree. I believe that it is useful to document the OAM design >> decision and that this document is a good starting point. >> >> Remember that the poll is not whether to publish this document >> at any particular time, but to accept it as a starting point for >> the work of the WG. >> >> As such I think the document is useful, and a good staring point, >> which is why I expressed the view that it should become a WG doc. >> >> Stewart >> >> >> >> Sadler, Jonathan B. wrote: >>> >>> I agree with Tom that this document seems to be more of a set of >>> meeting minutes/notes. I don't see any reasoned analysis - just a >>> statement of what is different between the two mechanisms and the >>> requirements along with a recommendation. >>> >>> The fact no discussion of inter-layer interactions is shown in >>> this document really concerns me as I believe its missing a key >>> difference between the approaches catalogued. >>> >>> If the document contained reasoned analysis and delt with all >>> issues, I would be able to support it. But in its current form it >>> is lacking the required substance. >>> >>> Jonathan Sadler >>> >>> ________________________________________ >>> From: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] On Behalf Of >>> Thomas D. Nadeau [tom.nadeau@bt.com] >>> Sent: Sunday, October 18, 2009 7:27 PM >>> To: Loa Andersson; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org >>> Subject: Re: [CCAMP] poll on making draft-sprecher-mpls-tp-oam- >>> analysis-07.txt a working group draft >>> >>> As I said earlier, I do not see the point in bringing this >>> document >>> forward. I viewed it more as a set of meeting minutes/notes that >>> were held >>> by the MEAD team, and as such has served its purpose. >>> >>> --Tom >>> >>> >>> >>> On 10/18/09 1:49 PM, "Loa Andersson" wrote: >>> >>> >>>> Working Group, >>>> >>>> the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have >>>> asked that the draft is adopted as an mpls working group document. >>>> >>>> This mail starts a two week poll on making the draft a working >>>> group >>>> document. Send a mail to the mpls-tp@ietf.org mailing list, >>>> indicating >>>> "yes/support" or "no/do not support". >>>> >>>> Comments on the content should be sent to the same mailing list >>>> with >>>> a different subject line. >>>> >>>> The poll ends Fri Oct 30. >>>> >>>> Loa and George >>>> MPLS working group co-chairs >>>> >>> >>> -- >>> Principal Architect - 21CN Networks >>> >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www.ietf.org/mailman/listinfo/pwe3 >>> >>> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 --Apple-Mail-1-822859124 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I like this idea. 




On Oct 21, 2009, at 12:53 PM, David Ward <dward@cisco.com> wrote:

Note that if we decide not to take the document in it's current form (history of decision making), the data could be incorporated into the OAM architecture draft under construction. We don't want to lose the information. 

-DWard

On Oct 20, 2009, at 4:51 AM, Stewart Bryant wrote:

I disagree. I believe that it is useful to document the OAM design
decision and that this document is a good starting point.

Remember that the poll is not whether to publish this document
at any particular time, but to accept it as a starting point for
the work of the WG.

As such I think the document is useful, and a good staring point,
which is why I expressed the view that it should become a WG doc.

Stewart



Sadler, Jonathan B. wrote: 
I agree with Tom that this document seems to be more of a set of meeting minutes/notes.  I don't see any reasoned analysis - just a statement of what is different between the two mechanisms and the requirements along with a recommendation.

The fact no discussion of inter-layer interactions is shown in this document really concerns me as I believe its missing a key difference between the approaches catalogued.

If the document contained reasoned analysis and delt with all issues, I would be able to support it.  But in its current form it is lacking the required substance.

Jonathan Sadler

________________________________________
From: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] On Behalf Of Thomas D. Nadeau [tom.nadeau@bt.com]
Sent: Sunday, October 18, 2009 7:27 PM
To: Loa Andersson; mpls-tp@ietf.org; pwe3@ietf.org; ccamp@ietf.org
Subject: Re: [CCAMP] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft

    As I said earlier, I do not see the point in bringing this document
forward. I viewed it more as a set of meeting minutes/notes that were held
by the MEAD team, and as such has served its purpose.

    --Tom



On 10/18/09 1:49 PM, "Loa Andersson" <loa@pi.nu> wrote:

  
Working Group,

the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have
asked that the draft is adopted as an mpls working group document.

This mail starts a two week poll on making the draft a working group
document. Send a mail to the mpls-tp@ietf.org mailing list, indicating
"yes/support" or "no/do not support".

Comments on the content should be sent to the same mailing list with
a different subject line.

The poll ends Fri Oct 30.

Loa and George
MPLS working group co-chairs
    

--
Principal Architect - 21CN Networks


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

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

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3
--Apple-Mail-1-822859124-- From gregb@grotto-networking.com Thu Oct 22 09:25:01 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FA483A681F for ; Thu, 22 Oct 2009 09:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clyf4qpl8nbY for ; Thu, 22 Oct 2009 09:25:00 -0700 (PDT) Received: from mail16c40.carrierzone.com (mail16c40.carrierzone.com [209.235.156.156]) by core3.amsl.com (Postfix) with ESMTP id 3E6453A6819 for ; Thu, 22 Oct 2009 09:25:00 -0700 (PDT) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by mail16c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id n9MGP9Sp013408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Oct 2009 16:25:14 GMT Message-ID: <4AE08760.6050406@grotto-networking.com> Date: Thu, 22 Oct 2009 09:25:04 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] Wavelength Conversion assumption for LSC interfaces... X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 16:25:01 -0000 Hi folks, as we've been preparing the first set of WSON documents for last call some questions have come up. We specify the wavelength conversion capabilities via potentially three sub-TLVs: (a) Wavelength Converter Accessibility sub-TLV (tell which ingress ports can reach which converters, and which converters can reach which output ports) (b) Wavelength Conversion Range Sub-TLV (tells range limits on wavelength converters) (c) Wavelength Converter Usage State Sub-TLV (tells us if a particular converter is being used) Now I was assuming that to indicate wavelength conversion was available at a node then (a) above would have to be present. However this only works if the default assumption for interfaces with ISCD = LSC (interface switching capability descriptor = lambda switch capable) is for "no wavelength conversion". Is this the assumption folks have used in deployments (or was the original intent in RFC4202, at the time I was working more the TDM side). If we can't make this assumption then we need to specify the wavelength conversion behavior explicitly for each ROADM, OXC, etc... Thanks ahead of time for your feedback Greg -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From root@core3.amsl.com Thu Oct 22 10:15:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DCC793A6809; Thu, 22 Oct 2009 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091022171501.DCC793A6809@core3.amsl.com> Date: Thu, 22 Oct 2009 10:15:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-wson-impairments-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 17:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments Author(s) : G. Bernstein Filename : draft-ietf-ccamp-wson-impairments-01.txt Pages : 35 Date : 2009-10-22 The operation of optical networks requires information on the physical characterization of optical network elements, subsystems, devices, and cabling. These physical characteristics may be important to consider when using a GMPLS control plane to support path setup and maintenance. This document discusses how the definition and characterization of optical fiber, devices, subsystems, and network elements contained in various ITU-T recommendations can be combined with GMPLS control plane protocols and mechanisms to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in optical networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-impairments-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-wson-impairments-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-22100527.I-D@ietf.org> --NextPart-- From choudarypally.subramanyam@wipro.com Wed Oct 21 16:50:51 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1508C28C118 for ; Wed, 21 Oct 2009 16:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.208 X-Spam-Level: X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsTF5f80mQE3 for ; Wed, 21 Oct 2009 16:50:47 -0700 (PDT) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id D8D193A6805 for ; Wed, 21 Oct 2009 16:50:46 -0700 (PDT) X-AuditID: cb5bdd57-b7c9eae000000d2c-6e-4adf9e5d28d2 Received: from blr-ec-aa03.wipro.com ( [10.201.18.42]) by (Symantec Mail Security) with SMTP id 84.43.03372.D5E9FDA4; Thu, 22 Oct 2009 05:20:53 +0530 (IST) Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-aa03.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 05:20:53 +0530 Received: from blr-ec-bh04.wipro.com ([10.201.50.98]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 05:20:53 +0530 Received: from HYD-MDP-MBX01.wipro.com ([10.150.50.181]) by blr-ec-bh04.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Oct 2009 05:20:53 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA52A9.52D602A8" Date: Thu, 22 Oct 2009 05:20:52 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt- regarding ISID error handling Thread-Index: AcpSqVK+wd2bKaYBS7qAjTlddLDxQg== From: To: X-OriginalArrivalTime: 21 Oct 2009 23:50:53.0263 (UTC) FILETIME=[53384DF0:01CA52A9] X-Brightmail-Tracker: AAAAAA== Subject: [CCAMP] draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt- regarding ISID error handling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 19:36:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA52A9.52D602A8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi , I am currently working on draft = "draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt" and I write this email = to seek some help from experts. I have two questions regarding the = Section 3 paragraph 6. 1) It say "An IB-BEB receiving a PATH message specifying one of its CNPs can locally determine which CBPs have internal connectivity to the I-component supporting the given CNP." How does the CSPF function select egress CNP, based on what criteria?=20 2) Further it says "On the other hand, if there is information on the service (I-SID) that the given ESP will support, then the IB-BEB MUST first determine which PIP and CBP is configured with the I-SID and MUST assign that CBP to the ESP"=20 a) What should be action taken if ISID received in PATH message is not = configured? Do I need to send PATH ERR message?=20 b) Assuming that I have received more than one ISID and each one belong = to different CBP port, in such case what should be the behavior? I am doing the manual configuration and association of ISID to CBP. Regards Choudarypally ------_=_NextPart_001_01CA52A9.52D602A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=

Hi ,

=0A=

I am currently working on draft = “draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt” and I write = this email to seek some help from experts. I have two questions = regarding the Section 3 paragraph 6.

=0A=

1) It say “An IB-BEB receiving a PATH message specifying = one
   of its CNPs can locally determine which CBPs have = internal
   connectivity to the I-component supporting the = given CNP.”

=0A=

How does the CSPF function select egress CNP, based on what criteria? =

=0A=

2) Further it says “On the other hand, if there is information = on
   the service (I-SID) that the given ESP will support, = then the IB-BEB
   MUST first determine which PIP and CBP = is configured with the I-SID
   and MUST assign that CBP to = the ESP”

=0A=

a) What should be action taken if ISID received in PATH message = is not configured? Do I need to send PATH ERR message? =
b) Assuming that I have received more than one ISID and each = one belong to different CBP port, in such case what should be the = behavior?

=0A=

 I am doing the manual configuration and association of ISID to = CBP.

=0A=

Regards
Choudarypally

------_=_NextPart_001_01CA52A9.52D602A8-- From zhangfatai@huawei.com Fri Oct 23 00:40:22 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1539228C0F5 for ; Fri, 23 Oct 2009 00:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.455 X-Spam-Level: * X-Spam-Status: No, score=1.455 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4m-Nv0ZuZybo for ; Fri, 23 Oct 2009 00:40:20 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 0B3FD3A6407 for ; Fri, 23 Oct 2009 00:40:20 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRY008SMIN7BJ@szxga01-in.huawei.com> for ccamp@ietf.org; Fri, 23 Oct 2009 15:40:19 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRY0090HIN7K2@szxga01-in.huawei.com> for ccamp@ietf.org; Fri, 23 Oct 2009 15:40:19 +0800 (CST) Received: from z41162b ([10.70.76.112]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRY00F1QIN68F@szxml06-in.huawei.com> for ccamp@ietf.org; Fri, 23 Oct 2009 15:40:19 +0800 (CST) Date: Fri, 23 Oct 2009 15:40:18 +0800 From: Fatai Zhang To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" Message-id: <04c101ca53b4$1164ae30$704c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_b8rT/iv/JD6j0Y1f9C755Q)" X-Priority: 3 X-MSMail-priority: Normal References: <077E41CFFD002C4CAB7DFA4386A532640167C3E9@DEMUEXC014.nsn-intra.net> <465531011AE4654BA0D30D01AB9EAA6E449EB8@FIESEXC030.nsn-intra.net> <328B9F5068825A48A4B8422A350B9047BC9D1E@CNBEEXC006.nsn-intra.net> <077E41CFFD002C4CAB7DFA4386A53264016B2EC2@DEMUEXC014.nsn-intra.net> <465531011AE4654BA0D30D01AB9EAA6E44A127@FIESEXC030.nsn-intra.net> <077E41CFFD002C4CAB7DFA4386A53264016DE8D7@DEMUEXC014.nsn-intra.net> Cc: "Clemens, Rainer \(NSN - DE/Munich\)" , "Soininen, Jonne \(NSN - FI/Espoo\)" , CCAMP Subject: Re: [CCAMP] I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 07:40:22 -0000 This is a multi-part message in MIME format. --Boundary_(ID_b8rT/iv/JD6j0Y1f9C755Q) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Nurit, Thanks for your comments. Please see below for in-line responses. Thanks Fatai Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) To: zhangfatai@huawei.com ; danli@huawei.com ; hanjianrui@huawei.com ; lihan@chinamobile.com Cc: Clemens, Rainer (NSN - DE/Munich) ; ccamp@ietf.org ; Soininen, Jonne (NSN - FI/Espoo) Sent: Thursday, October 22, 2009 1:42 AM Subject: RE: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt Dear authors, Thanks for submitting your document on "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks". We have reviewed the document and we are a little bit concerned to find out that some significant items described in the document are not aligned with what is defined in G.709. Especially the mappings into ODU3e1 and ODU3e2 are only defined in G.Sup43 which is not a standard. In addition G.Sup43 does not define mappings of ODU0, ODU1, ODU2 and ODUflex into ODU3e2. The only mappings that are defined in G.Sup43 are 4x ODU2e. [Fatai] Yes, you are right and we also indicated in this draft that ODU3e1 and ODU3e2 are defined in G.Sup43. You know G.Sup is not standard currently,so I think we have some options for this. (1)add a note to explain that ODU3e1 and ODU3e2 are still non-standard explicitly (2) change the title of this draft to "Framework for GMPLS and PCE Control of Optical Transport Networks" (3) move ODU3e2 to an appendix. In addition, I think we can cover ODU3e1 and ODU3e2 in this draft at this stage (i.e., individual draft), because they are being developed in ITU-T and may be accepted by ITU-T some day. I will reflect this in the next version. We are afraid that this is not inline with the view of the majority of participants in SG15/Q11. [Fatai] I don't know whether it is true or not. But I think we can hear the opinions from SG15/Q11. Except of the extensions that are already described in two draft (draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn, draft-zhang-ccamp-gmpls-evolving-g709), all other content of section 3, 4 is copied from ITU standards. Would not it be better to just refer to the ITU-T document? [Fatai] In Section 3, some part of information is from G.709 and G.872 and we reference this recommendations explicitly. We just try to give a brief overview of OTN to CCAMP experts from the perspective of Control Plane and make everyone quickly understand why we need more considerations on OTN control. I think it is really tough for everyone to go through G.709, G.872 and other recommendations detailedly. As for Section 4, I don't know why you said that it is copied from ITU standards. In Section 4, it describes the connection management model for OTN networks, which is based on our understanding and some discussions in ITU-T Q12. Best regards, Nurit > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext > Internet-Drafts@ietf.org > Sent: Friday, October 16, 2009 11:45 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > Title : Framework for GMPLS and PCE Control > of G.709 Optical Transport Networks > Author(s) : F. Zhang, et al. > Filename : draft-zhang-ccamp-gmpls-g709-framework-00.txt > Pages : 27 > Date : 2009-10-16 > > This document provides a framework for applying Generalized Mulit- > Protocol Label Switching (GMPLS) and the Path Computation Element > (PCE) architecture to the control of G.709 Optical Transport Networks > (OTN) as specified in the ITU-T G.709 recommendation, including the > enhanced functionality in the recently consented revision. > > > > > zhang > > > > > > Expires April 2010 > > > > > > [page 1] > > draft-zhang-ccamp-gmpls-g709-framework-00.txt > > > > October 2009 > > > Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zhang-ccamp-gmpls-g7 > 09-framework-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > --Boundary_(ID_b8rT/iv/JD6j0Y1f9C755Q) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi Nurit,
 
Thanks for your comments.
 
Please see below for in-line responses.
 
 
 
 
 
Thanks
 
Fatai
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
----- Original Message -----
Sent: Thursday, October 22, 2009 1:42 AM
Subject: RE: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

 

Dear authors,

 

Thanks for submitting your document on "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks".

 

We have reviewed the document and we are a little bit concerned to find out that some significant items described in the document are not aligned with what is defined in G.709.

 

Especially the mappings into ODU3e1 and ODU3e2 are only defined in G.Sup43 which is not a standard.

In addition G.Sup43 does not define mappings of ODU0, ODU1, ODU2 and ODUflex into ODU3e2. The only mappings that are defined in G.Sup43 are 4x ODU2e.

 

[Fatai] Yes, you are right and we also indicated in this draft that ODU3e1 and ODU3e2 are defined in G.Sup43. You know G.Sup is not standard currently,so I think we have some options for this. (1)add a note to explain that ODU3e1 and ODU3e2 are still non-standard explicitly (2) change the title of this draft to "Framework for GMPLS and PCE Control of Optical Transport Networks" (3) move ODU3e2  to an appendix. 

In addition, I think we can cover ODU3e1 and ODU3e2 in this draft at this stage (i.e., individual draft), because they are being developed in ITU-T and may be accepted by ITU-T some day.

I will reflect this in the next version.

 

We are afraid that this is not inline with the view of the majority of participants in SG15/Q11.

 

[Fatai] I don't know whether it is true or not. But I think we can hear the opinions from SG15/Q11.

 

Except of the extensions that are already described in two draft (draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn, draft-zhang-ccamp-gmpls-evolving-g709), all other content of section 3, 4 is copied from ITU standards. Would not it be better to just refer to the ITU-T document?

 

[Fatai]  In Section 3, some part of information is from G.709 and G.872 and we reference this recommendations explicitly. We just try to give a brief overview of OTN to CCAMP experts from the perspective of Control Plane and make everyone quickly understand why we need more considerations on OTN control. I think it is really tough for everyone to go through G.709, G.872 and other recommendations detailedly. As for  Section 4, I don't know why you said that it is copied from ITU standards.  In Section 4, it describes the connection management model for OTN networks, which is based on our understanding and some discussions in ITU-T Q12. 

 

Best regards,

Nurit

 

 

 

>

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

> From: i-d-announce-bounces@ietf.org

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

> Internet-Drafts@ietf.org

> Sent: Friday, October 16, 2009 11:45 AM

> To: i-d-announce@ietf.org

> Subject: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

>

> A New Internet-Draft is available from the on-line

> Internet-Drafts directories.

>

>     Title           : Framework for GMPLS and PCE Control

> of G.709 Optical Transport Networks

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

>     Filename        : draft-zhang-ccamp-gmpls-g709-framework-00.txt

>     Pages           : 27

>     Date            : 2009-10-16

>

> This document provides a framework for applying Generalized Mulit-

> Protocol Label Switching (GMPLS) and the Path Computation Element

> (PCE) architecture to the control of G.709 Optical Transport Networks

> (OTN) as specified in the ITU-T G.709 recommendation, including the

> enhanced functionality in the recently consented revision.

>

> 

> 

> 

> zhang

>

>

>

>

>

>   Expires April 2010

>

>

>

>

>

>   [page 1]

>

> draft-zhang-ccamp-gmpls-g709-framework-00.txt

>

>

>

>   October 2009

> 

>

> Conventions used in this document

>

> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

> document are to be interpreted as described in [RFC2119].

>

> A URL for this Internet-Draft is:

> http://www.ietf.org/internet-drafts/draft-zhang-ccamp-gmpls-g7

> 09-framework-00.txt

>

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

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

>

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

> implementation to automatically retrieve the ASCII version of the

> Internet-Draft.

>

--Boundary_(ID_b8rT/iv/JD6j0Y1f9C755Q)-- From zhangfatai@huawei.com Fri Oct 23 02:31:41 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7E153A69FD for ; Fri, 23 Oct 2009 02:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.225 X-Spam-Level: * X-Spam-Status: No, score=1.225 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LXCjkW7WM9d for ; Fri, 23 Oct 2009 02:31:41 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id D56A73A6A0F for ; Fri, 23 Oct 2009 02:31:40 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRY00IVMNSSQ2@szxga01-in.huawei.com> for ccamp@ietf.org; Fri, 23 Oct 2009 17:31:41 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRY002YHNSS4P@szxga01-in.huawei.com> for ccamp@ietf.org; Fri, 23 Oct 2009 17:31:40 +0800 (CST) Received: from z41162b ([10.70.76.112]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRY00D0PNSSS1@szxml04-in.huawei.com> for ccamp@ietf.org; Fri, 23 Oct 2009 17:31:40 +0800 (CST) Date: Fri, 23 Oct 2009 17:31:40 +0800 From: Fatai Zhang To: CCAMP Message-id: <05e001ca53c3$a02e2fb0$704c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_k//lULjc1CZIg1yjVI24IQ)" X-Priority: 3 X-MSMail-priority: Normal Subject: [CCAMP] OTN control drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 09:31:41 -0000 This is a multi-part message in MIME format. --Boundary_(ID_k//lULjc1CZIg1yjVI24IQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi CCAMPers, You know that there are lots of interests from both a technical and organizational standpoint (e.g., ITU-T SG15/Q12,Q14, IETF CCAMP) on OTN control, since draft-zhang-ccamp-gmpls-evolving-g709-00.txt was presented in IETF 75th meeting. You also know that [G.709 V3] including ODU0, ODU4, ODUflex... was consented by ITU-T SG15 in this October. Therefore, in order to control and manage the OTN networks efficiently, OTN control is really important for the industry. Up to now, we have five drafts about OTN control: (1) draft-zhang-ccamp-gmpls-g709-framework-00.txt (2) draft-zhang-ccamp-gmpls-evolving-g709-03.txt (3) draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt (4) draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt (5) draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt To promote better understanding or the discussions in Hiroshima meeting, we'd appreciate your review and comments. Thanks Authors of these drafts --Boundary_(ID_k//lULjc1CZIg1yjVI24IQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi CCAMPers,
 
You know that there are lots of interests from both a technical and organizational standpoint (e.g., ITU-T SG15/Q12,Q14, IETF CCAMP) on OTN control, since draft-zhang-ccamp-gmpls-evolving-g709-00.txt was presented in IETF 75th meeting.
 
You also know that [G.709 V3] including ODU0, ODU4, ODUflex... was consented by ITU-T SG15 in this October.  Therefore, in order to control and manage the OTN networks efficiently, OTN control is really important for the industry.
 
Up to now, we have five drafts about OTN control:
 
To promote better understanding or the discussions in Hiroshima meeting, we'd appreciate your review and comments.
 
 
Thanks
 
Authors of these drafts
 
 
--Boundary_(ID_k//lULjc1CZIg1yjVI24IQ)-- From nurit.sprecher@nsn.com Fri Oct 23 06:46:16 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5478E3A686C for ; Fri, 23 Oct 2009 06:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys+U9HbVIZ9o for ; Fri, 23 Oct 2009 06:46:07 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id B1CA33A63EB for ; Fri, 23 Oct 2009 06:46:05 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9NDf0RN001809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 23 Oct 2009 15:41:00 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9NDf0OA009373; Fri, 23 Oct 2009 15:41:00 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 15:40:59 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA53E6.7449F28F" Date: Fri, 23 Oct 2009 15:40:56 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A532640170D04C@DEMUEXC014.nsn-intra.net> In-Reply-To: <04c101ca53b4$1164ae30$704c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt Thread-Index: AcpTtB52oHMcYaztQFuaBCRUFnH9LgAMJ1Fg References: <077E41CFFD002C4CAB7DFA4386A532640167C3E9@DEMUEXC014.nsn-intra.net> <465531011AE4654BA0D30D01AB9EAA6E449EB8@FIESEXC030.nsn-intra.net> <328B9F5068825A48A4B8422A350B9047BC9D1E@CNBEEXC006.nsn-intra.net> <077E41CFFD002C4CAB7DFA4386A53264016B2EC2@DEMUEXC014.nsn-intra.net> <465531011AE4654BA0D30D01AB9EAA6E44A127@FIESEXC030.nsn-intra.net> <077E41CFFD002C4CAB7DFA4386A53264016DE8D7@DEMUEXC014.nsn-intra.net> <04c101ca53b4$1164ae30$704c460a@china.huawei.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Fatai Zhang" X-OriginalArrivalTime: 23 Oct 2009 13:40:59.0989 (UTC) FILETIME=[74C15050:01CA53E6] Cc: "Clemens, Rainer \(NSN - DE/Munich\)" , "Soininen, Jonne \(NSN - FI/Espoo\)" , CCAMP Subject: Re: [CCAMP] I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 13:46:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA53E6.7449F28F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fatai, Thanks for your response. =20 Referring to a document which is not a standard is problematic and even confusing. I am not sure that all the IETF colleagues could realize that a supplement document in the ITU-T is not considered as a standard. As you agreed below, G.Sup43 is NOT a standard.=20 I believe it is NOT in the scope of CCAMP to define the dataplane behavior of ODU switching...we can define a control plane for a standard dataplane and refer to the dataplane standard behavior.=20 Once (and if) it is defined as a standard behavior in the ITU-T, there will be room to specify an extension for GMPLS (if necessary) to support it.=20 =20 Also, I would like to note that it was NEVER discussed in SG1/Q11 to allow other mappings than ODU2e into ODU3e. It was even explicitly stated that no other mapping should be described in G.Sup43. The WP3 report from the plenary in December 2008 states that :"After discussion, the agreement was reached to document two versions of ODU3e, one based on the Huawei and CMCC proposal (using the eventual GMP chosen for ODU4) and the other based on the NTT and Japan proposals. Agreement was reached to only document the mapping of four 10GBASE-R clients into each of these two versions of ODU3e in an updated G.Sup43.". =20 Nevertheless, even if specified in G.Sup43, we need to keep in mind that this is NOT a standard and we cannot refer to it as such. =20 Best regards, Nurit =20 ________________________________ From: ext Fatai Zhang [mailto:zhangfatai@huawei.com]=20 Sent: Friday, October 23, 2009 9:40 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: Clemens, Rainer (NSN - DE/Munich); CCAMP; Soininen, Jonne (NSN - FI/Espoo); Li Dan; han jianrui; lihan@chinamobile.com Subject: Re: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt =20 Hi Nurit, =20 Thanks for your comments. =20 Please see below for in-line responses. =20 =20 =20 =20 =20 Thanks =20 Fatai =20 Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message -----=20 From: Sprecher, Nurit (NSN - IL/Hod HaSharon) =20 To: zhangfatai@huawei.com ; danli@huawei.com ; hanjianrui@huawei.com ; lihan@chinamobile.com=20 Cc: Clemens, Rainer (NSN - DE/Munich) ; ccamp@ietf.org ; Soininen, Jonne (NSN - FI/Espoo) =20 Sent: Thursday, October 22, 2009 1:42 AM Subject: RE: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt =20 =20 Dear authors,=20 =20 Thanks for submitting your document on "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks". =20 We have reviewed the document and we are a little bit concerned to find out that some significant items described in the document are not aligned with what is defined in G.709. =20 Especially the mappings into ODU3e1 and ODU3e2 are only defined in G.Sup43 which is not a standard.=20 In addition G.Sup43 does not define mappings of ODU0, ODU1, ODU2 and ODUflex into ODU3e2. The only mappings that are defined in G.Sup43 are 4x ODU2e. =20 [Fatai] Yes, you are right and we also indicated in this draft that ODU3e1 and ODU3e2 are defined in G.Sup43. You know G.Sup is not standard currently,so I think we have some options for this. (1)add a note to explain that ODU3e1 and ODU3e2 are still non-standard explicitly (2) change the title of this draft to "Framework for GMPLS and PCE Control of Optical Transport Networks" (3) move ODU3e2 to an appendix. In addition, I think we can cover ODU3e1 and ODU3e2 in this draft at this stage (i.e., individual draft), because they are being developed in ITU-T and may be accepted by ITU-T some day. I will reflect this in the next version.=20 =20 =20 We are afraid that this is not inline with the view of the majority of participants in SG15/Q11. =20 [Fatai] I don't know whether it is true or not. But I think we can hear the opinions from SG15/Q11. =20 Except of the extensions that are already described in two draft (draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn, draft-zhang-ccamp-gmpls-evolving-g709), all other content of section 3, 4 is copied from ITU standards. Would not it be better to just refer to the ITU-T document? =20 [Fatai] In Section 3, some part of information is from G.709 and G.872 and we reference this recommendations explicitly. We just try to give a brief overview of OTN to CCAMP experts from the perspective of Control Plane and make everyone quickly understand why we need more considerations on OTN control. I think it is really tough for everyone to go through G.709, G.872 and other recommendations detailedly. As for Section 4, I don't know why you said that it is copied from ITU standards. In Section 4, it describes the connection management model for OTN networks, which is based on our understanding and some discussions in ITU-T Q12.=20 =20 Best regards, Nurit =20 =20 =20 >=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org=20 > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext=20 > Internet-Drafts@ietf.org > Sent: Friday, October 16, 2009 11:45 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Framework for GMPLS and PCE Control=20 > of G.709 Optical Transport Networks > Author(s) : F. Zhang, et al. > Filename : draft-zhang-ccamp-gmpls-g709-framework-00.txt > Pages : 27 > Date : 2009-10-16 >=20 > This document provides a framework for applying Generalized Mulit- > Protocol Label Switching (GMPLS) and the Path Computation Element=20 > (PCE) architecture to the control of G.709 Optical Transport Networks=20 > (OTN) as specified in the ITU-T G.709 recommendation, including the=20 > enhanced functionality in the recently consented revision.=20 >=20 > =20 > =20 > =20 > zhang >=20 >=20 >=20 >=20 >=20 > Expires April 2010 >=20 >=20 >=20 >=20 >=20 > [page 1]=20 >=20 > draft-zhang-ccamp-gmpls-g709-framework-00.txt >=20 >=20 >=20 > October 2009=20 > =20 >=20 > Conventions used in this document=20 >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20 > document are to be interpreted as described in [RFC2119]. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zhang-ccamp-gmpls-g7 > 09-framework-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 ------_=_NextPart_001_01CA53E6.7449F28F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Fatai,

Thanks for your = response.

 

=

Referring to a document which is = not a standard is problematic and even confusing. I am not sure that all the IETF = colleagues could realize that a supplement document in the ITU-T is not considered = as a standard. As you agreed below, G.Sup43 is NOT a standard. =

I believe it is NOT in the scope = of CCAMP to define the dataplane behavior of ODU switching…we can define a = control plane for a standard dataplane and refer to the dataplane standard = behavior.

Once (and if) it is defined as a = standard behavior in the ITU-T, there will be room to specify an extension for = GMPLS (if necessary) to support it.

 

=

Also, I would like to note that it = was NEVER discussed in SG1/Q11 to allow other mappings than ODU2e into = ODU3e. It was even explicitly stated that no other mapping should be described in = G.Sup43. The WP3 report from the plenary in December 2008 states that = :"After discussion, the agreement was reached to document two versions of ODU3e, = one based on the Huawei and CMCC proposal (using the eventual GMP chosen for = ODU4) and the other based on the NTT and Japan proposals.  Agreement was reached to only = document the mapping of four 10GBASE-R clients into each of these two versions of = ODU3e in an updated G.Sup43.".

 

Nevertheless, even if specified in G.Sup43, we need to keep in mind that this is NOT a standard and we = cannot refer to it as such.

 

Best = regards,

Nurit

 

From: ext = Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Friday, October 23, = 2009 9:40 AM
To: Sprecher, Nurit (NSN = - IL/Hod HaSharon)
Cc: Clemens, Rainer (NSN = - DE/Munich); CCAMP; Soininen, Jonne (NSN - FI/Espoo); Li Dan; han = jianrui; lihan@chinamobile.com
Subject: Re: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

 

Hi Nurit,

 

Thanks for your = comments.

 

Please see below = for in-line responses.

 

 

 

 

 

Thanks

 

Fatai
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

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

Sent: = Thursday, October 22, 2009 1:42 AM

Subject: RE: = I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

 

 

Dear authors,

 

Thanks for submitting your document on "Framework for GMPLS = and PCE Control of G.709 Optical Transport = Networks".

 

We have reviewed the document and we are a little bit concerned = to find out that some significant items described in the document are not = aligned with what is defined in G.709.

 

Especially the mappings into ODU3e1 and = ODU3e2 are only defined in G.Sup43 which is not a standard. =

In addition G.Sup43 does not define mappings = of ODU0, ODU1, ODU2 and ODUflex into ODU3e2. The only mappings that = are defined in G.Sup43 are 4x ODU2e.

 

[Fatai] Yes, you are right and we = also indicated in this draft that ODU3e1 and ODU3e2 are defined in G.Sup43. You know G.Sup = is not standard currently,so I think we have some options for this. (1)add a = note to explain that ODU3e1 and ODU3e2 are still non-standard explicitly (2) = change the title of this draft to "Framework for GMPLS and PCE Control of = Optical Transport Networks" (3) move ODU3e2  to an = appendix. 

In addition, I think we can cover = ODU3e1 and ODU3e2 in this draft at this stage (i.e., individual draft), because = they are being developed in ITU-T and may be accepted by ITU-T some = day.

I will reflect this in the next = version.

 

 

We are afraid that this is not inline with the view of the = majority of participants in SG15/Q11.

 

[Fatai] I don't = know whether it is true or not. But I think we can hear the opinions from = SG15/Q11.

 

Except of the extensions that are already described in two draft (draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn, = draft-zhang-ccamp-gmpls-evolving-g709), all other content of section 3, 4 is copied from ITU standards. Would = not it be better to just refer to the ITU-T document?

 

[Fatai] In = Section 3, some part of information is from G.709 and G.872 and we reference = this recommendations explicitly. We just try to give a brief overview of OTN = to CCAMP experts from the perspective of Control Plane and make everyone = quickly understand why we need more considerations on OTN control. I think it is = really tough for everyone to go through G.709, G.872 and other recommendations detailedly. As for  Section 4, I don't know why you said that = it is copied from ITU standards.  In Section 4, it describes the = connection management model for OTN networks, which is based on our = understanding and some discussions in ITU-T Q12. 

 

Best regards,

Nurit

 

 

 

>

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

> From: i-d-announce-bounces@ietf.org =

> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext =

> Internet-Drafts@ietf.org

> Sent: Friday, October 16, 2009 11:45 = AM

> To: i-d-announce@ietf.org

> Subject: I-D = Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt =

>

> A New Internet-Draft is available from the on-line =

> Internet-Drafts directories.

>

>     Title           : = Framework for GMPLS and PCE Control

> of G.709 Optical Transport = Networks

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

>     Filename        : draft-zhang-ccamp-gmpls-g709-framework-00.txt

>     Pages           : = 27

>     Date            : 2009-10-16

>

> This document provides a framework for applying Generalized = Mulit-

> Protocol Label Switching (GMPLS) and the Path Computation = Element

> (PCE) architecture to the control of G.709 Optical = Transport Networks

> (OTN) as specified in the ITU-T G.709 recommendation, = including the

> enhanced functionality in the recently consented revision. =

>

> 

> 

> 

> zhang

>

>

>

>

>

>   Expires April 2010

>

>

>

>

>

>   [page 1]

>

> = draft-zhang-ccamp-gmpls-g709-framework-00.txt

>

>

>

>   October 2009

> 

>

> Conventions used in this document =

>

> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", =

> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this

> document are to be interpreted as described in = [RFC2119].

>

> A URL for this Internet-Draft = is:

> = http://www.ietf.org/internet-drafts/draft-zhang-ccamp-gmpls-g7=

> 09-framework-00.txt

>

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

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

>

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

> implementation to automatically retrieve the ASCII version = of the

> Internet-Draft.

>

------_=_NextPart_001_01CA53E6.7449F28F-- From wwwrun@core3.amsl.com Fri Oct 23 10:23:57 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 4983B3A68B8; Fri, 23 Oct 2009 10:23:56 -0700 (PDT) To: lberger@labn.net, nabil.n.bitar@verizon.com, donald.fedyk@alcatel-lucent.com, nurit.sprecher@nsn.com, attila.takacs@ericsson.com, diego.caviglia@ericsson.com, alan.mcguire@bt.com, david.i.allan@ericsson.com, hshah@force10networks.com From: IETF Secretariat Message-Id: <20091023172357.4983B3A68B8@core3.amsl.com> Date: Fri, 23 Oct 2009 10:23:57 -0700 (PDT) Cc: ccamp@ietf.org, ipr-announce@ietf.org, adrian.farrel@huawei.com, rcallon@juniper.net Subject: [CCAMP] Posting of IPR Disclosure related to Update to Nortel Networks Statement of IPR related to draft-ietf-ccamp-gmpls-ethernet-pbb-te X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 17:23:57 -0000 Dear Lou Berger, Nabil Bitar, Don Fedyk, Nurit Sprecher, Attila Takacs, Diego Caviglia, Alan McGuire, David Allan, Himanshu Shah: An IPR disclosure that pertains to your Internet-Draft entitled "Generalized Multiprotocol Label Switching (GMPLS) control of Ethernet PBB-TE" (draft-ietf-ccamp-gmpls-ethernet-pbb-te) was submitted to the IETF Secretariat on 2009-04-29 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1195/). The title of the IPR disclosure is "Update to Nortel Networks Statement of IPR related to draft-ietf-ccamp-gmpls-ethernet-pbb-te." The IETF Secretariat From loa@pi.nu Sat Oct 24 13:20:08 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3683A682A; Sat, 24 Oct 2009 13:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+Q2GE1UCjWL; Sat, 24 Oct 2009 13:20:08 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 095743A66B4; Sat, 24 Oct 2009 13:20:07 -0700 (PDT) Received: from [192.168.0.100] (h133n2fls33o883.telia.com [217.208.62.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id AE36FD404F; Sat, 24 Oct 2009 22:20:16 +0200 (CEST) Message-ID: <4AE3617D.3010008@pi.nu> Date: Sat, 24 Oct 2009 22:20:13 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" , mpls@ietf.org, pwe3@ietf.org, ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] mpls-tp slots in Hiroshima X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2009 20:20:09 -0000 All, I've been asked what mpls, mpls-tp and pwe3 meetings that are planned for Hiroshima. Earlier we have had problems completing the "classical" mpls and mpls-tp in two sessions. Given that the there are no changes in the agenda as i looks today that effect working groups that do mpls-tp work the following is the plan: 1. Monday 17.40 - 19.20 Orchid Centre Multiprotocol Label Switching WG This meeting will start with the mpls drafts, but is likely to address some mpls-tp drafts towards the end 2. Wednesday 09.00 - 11.30 Orchid East Multiprotocol Label Switching WG This meeting is planned to address mpls-tp drafts only The agenda says that there is a morning break at 10.15 but we will ignore that and a 2.5 hours meeting. 3. Thursday 13.00 - 15.00 Orchid West Pseudowire Emulation Edge to Edge WG This meeting will address classical pwe3 drafts 4. Friday 09.00 - 11.30 Acacia West Pseudowire Emulation Edge to Edge WG This meeting is intended to address mpls-tp drafts There are also some mpls-tp drafts that will be discussed in the ccamp working group, mostly control plane related. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From Yechiel.Rosengarten@ecitele.com Sun Oct 25 01:23:52 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAE643A6944 for ; Sun, 25 Oct 2009 01:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSczNRlWOzDW for ; Sun, 25 Oct 2009 01:23:46 -0700 (PDT) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 80F2C3A68A9 for ; Sun, 25 Oct 2009 01:23:45 -0700 (PDT) Received: from ilptexfe.ecitele.com (HELO ILPTEXCH02.ecitele.com) ([147.234.245.181]) by ilptiron01.ecitele.com with ESMTP; 25 Oct 2009 10:14:57 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sun, 25 Oct 2009 10:23:52 +0200 From: Yechiel Rosengarten To: Fatai Zhang , CCAMP Date: Sun, 25 Oct 2009 10:23:24 +0200 Thread-Topic: [CCAMP] OTN control drafts: draft-zhang-ccamp-gmpls-g709-framework-00.txt: Thread-Index: AcpTw6uvQCrAI6zCR6+M0sDh1YX2OgBguYIA Message-ID: <93BC09B2B8795C49B4E3453CE6A45A18A1B27CF269@ILPTMAIL02.ecitele.com> References: <05e001ca53c3$a02e2fb0$704c460a@china.huawei.com> In-Reply-To: <05e001ca53c3$a02e2fb0$704c460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_93BC09B2B8795C49B4E3453CE6A45A18A1B27CF269ILPTMAIL02eci_" MIME-Version: 1.0 Subject: Re: [CCAMP] OTN control drafts: draft-zhang-ccamp-gmpls-g709-framework-00.txt: X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 08:23:52 -0000 --_000_93BC09B2B8795C49B4E3453CE6A45A18A1B27CF269ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Some questions about draft-zhang-ccamp-gmpls-g709-framework-00.txt: 1. " 3.1.2.2. Optical channel data unit (ODUk) The optical channel data unit (ODUk) provides adaptation of client signals via the Optical Channel Payload Unit (OPUk) LO ODU (Lower order ODU) can be multiplexed into HO ODU (higher order ODU), which is described in section 3.2.2. Currently, the following ODUk types are defined: ODU0, ODU1, ODU2, ODU3, ODU4, ODU2e, ODUflex, ODU3e1, ODU3e2. ODUk has a bandwidth/bit rate BR and a bit rate tolerance T i.e. ODU(BR,T). The detailed bit rates and tolerance of the ODUk signals (except ODUflex) are defined in [ITUT-G709], [Gsup43] and [G709-V3]. The bitrat= e and tolerance of the ODUflex is dependent on the client signal. HO ODUk types are: ODU1, ODU2, ODU3, ODU4, ODU3e1, ODU3e2. LO ODUk types are: ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4, ODUflex. ODU3e1 and ODU3e2 can be treated as LO ODU signals outside the domain in= which these signals terminate. " I wonder why ODU4 is included as LO ODUk type. It cannot be multiplexed to = any higher order ODUk 2. " Take the following Figure 6 as an example, the single topology containing links and matrices can be illustrated as follows: LO ODU Link #1: HO ODU2, support transport of ODU0, ODU1, ODU2; LO ODU Link #2: HO ODU3, support transport of ODU0, ODU1, ODU2, ODU3; LO ODU Link #3: HO ODU2, support transport of ODU0, ODU1, ODU2; LO ODU Link #4: HO ODU1, support transport of ODU0; LO ODU Link #5: HO ODU1, support transport of ODU0; LO ODU Matrix A LO ODU Matrix B LO ODU Matrix C LO ODU Matrix D LO ODU Matrix E " Why link #4 and #5 do not support transport of ODU1? Is there any concept t= o do this exception compared to the other links? Best Regards, Yechiel Rosengarten System Engineering ECI Telecom Ltd e-mail: yechiel.rosengarten@ecitele.com From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of F= atai Zhang Sent: Friday, October 23, 2009 11:32 AM To: CCAMP Subject: [CCAMP] OTN control drafts Hi CCAMPers, You know that there are lots of interests from both a technical and organiz= ational standpoint (e.g., ITU-T SG15/Q12,Q14, IETF CCAMP) on OTN control, s= ince draft-zhang-ccamp-gmpls-evolving-g709-00.txt was presented in IETF 75t= h meeting. You also know that [G.709 V3] including ODU0, ODU4, ODUflex... was consente= d by ITU-T SG15 in this October. Therefore, in order to control and manage= the OTN networks efficiently, OTN control is really important for the indu= stry. Up to now, we have five drafts about OTN control: (1) draft-zhang-ccamp-gmpls-g709-framework-00.txt (2) draft-zhang-ccamp-gmpls-evolving-g709-03.txt (3) draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt (4) draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt (5) draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt To promote better understanding or the discussions in Hiroshima meeting, we= 'd appreciate your review and comments. Thanks Authors of these drafts --_000_93BC09B2B8795C49B4E3453CE6A45A18A1B27CF269ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Some questions about draft-zhang-ccamp-gmpls-g709-fra= mework-00.txt:

1.

“

3.1.2.2. Optical channel data unit (ODUk)

 &nb= sp; The optical channel data unit (ODUk) provides adaptation of client

   signals via the Optical Chan= nel Payload Unit (OPUk) LO ODU (Lower

   order ODU) can be multiplexe= d into HO ODU (higher order ODU), which

   is described in section 3.2.2.

 

   Currently, the following ODU= k types are defined: ODU0, ODU1, ODU2,

   ODU3, ODU4, ODU2e, ODUflex, ODU3e1, ODU3e2. ODUk has a bandwidth/bit

   rate BR and a bit rate toler= ance T i.e. ODU(BR,T). The detailed bit

   rates and tolerance of the O= DUk signals (except ODUflex) are defined

   in [IT= UT-G709], [Gsup43<= /a>] and [G709-V3]. The bit= rate and tolerance of

   the ODUflex is dependent on = the client signal.

 

   HO ODUk types are: ODU1, ODU= 2, ODU3, ODU4, ODU3e1, ODU3e2.

 

   LO ODUk types are: ODU0, ODU= 1, ODU2, ODU2e, ODU3, ODU4, ODUflex.

   ODU3e1 and ODU3e2 can be tre= ated as LO ODU signals outside the domain in which these signals terminate.=

”

 

I wonder why ODU4 is included as LO ODUk type. It cannot be multiplexed to an= y higher order ODUk

 

2.

  “

Take the following Figure 6 as an example= , the single topology

   containing links and matrice= s can be illustrated as follows:

 

   LO ODU Link #1: HO ODU2, sup= port transport of ODU0, ODU1, ODU2;

 

   LO ODU Link #2: HO ODU3, sup= port transport of ODU0, ODU1, ODU2, ODU3;

 

   LO ODU Link #3: HO ODU2, sup= port transport of ODU0, ODU1, ODU2;

 

   LO ODU Link #4: HO ODU1, sup= port transport of ODU0;

 

   LO ODU Link #5: HO ODU1, sup= port transport of ODU0;

 

   LO ODU Matrix A

 

   LO ODU Matrix B

 

   LO ODU Matrix C

 

   LO ODU Matrix D

 

   LO ODU Matrix E

“

Why link #4 and #5 do not support transport of ODU1? Is there any concept to do this exception compared to the other links?

 

Best Regards,

 

     Yechiel Rosengarten
     System Engineering
     ECI Telecom Ltd
     e-mail: yechiel.rosengarten@ecitele.com

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Fatai Zhang
Sent: Friday, October 23, 2009 11:32 AM
To: CCAMP
Subject: [CCAMP] OTN control drafts

 

Hi CCAMPers,

 

You know that there are lots of interests from both a technical and organizatio= nal standpoint (e.g., ITU-T SG15/Q12,Q14, IETF CCAMP) on OTN control, since draft-zhang-ccamp-gmpls-evolving-g709-00.txt was presented in IETF 75th meeting.

 

You also know that [G.709 V3] including ODU0, ODU4, ODUflex... was consented by ITU-T SG15 in this October.  Therefore, in order to control and manage= the OTN networks efficiently, OTN control is really important for the industry.=

 

Up to now, we have five drafts about OTN control:

 

To promote better understanding or the discussions in Hiroshima meeting, we'd appreciate your review and comments.

 

 

Thanks

 

Authors of these drafts

 

 

--_000_93BC09B2B8795C49B4E3453CE6A45A18A1B27CF269ILPTMAIL02eci_-- From Yechiel.Rosengarten@ecitele.com Sun Oct 25 02:05:40 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 476143A68F7 for ; Sun, 25 Oct 2009 02:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vlNDyftNZLS for ; Sun, 25 Oct 2009 02:05:36 -0700 (PDT) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id CF0493A67FA for ; Sun, 25 Oct 2009 02:05:34 -0700 (PDT) Received: from ilptexfe.ecitele.com (HELO ILPTEXCH02.ecitele.com) ([147.234.245.181]) by ilptiron01.ecitele.com with ESMTP; 25 Oct 2009 10:56:49 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Sun, 25 Oct 2009 11:05:38 +0200 From: Yechiel Rosengarten To: Fatai Zhang , CCAMP Date: Sun, 25 Oct 2009 11:05:12 +0200 Thread-Topic: [CCAMP] OTN control drafts: draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt Thread-Index: AcpTw6uvQCrAI6zCR6+M0sDh1YX2OgBjPeyg Message-ID: <93BC09B2B8795C49B4E3453CE6A45A18A1B27CF2A1@ILPTMAIL02.ecitele.com> References: <05e001ca53c3$a02e2fb0$704c460a@china.huawei.com> In-Reply-To: <05e001ca53c3$a02e2fb0$704c460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_93BC09B2B8795C49B4E3453CE6A45A18A1B27CF2A1ILPTMAIL02eci_" MIME-Version: 1.0 Subject: Re: [CCAMP] OTN control drafts: draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 09:05:40 -0000 --_000_93BC09B2B8795C49B4E3453CE6A45A18A1B27CF2A1ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >From Paragraph 3.2 of the draft: " 3.2. Verify Transport Mechanism . . . . . Capability of transmitting Test messages using ODUk Trail Trace Identifier (TTI) overhead with frame length of 64 bytes. See ITU G.709 Section 15.2 and Section 15.8 for the s= tructure and definition. The Test message is sent according to [RFC4204]. - 0x04 GCC0: Test Message over the GCC0 Capability of transmitting Test messages using the OTUk Overhead General Communications Channel (GCC0). See ITU G.709 Section 15.7 for the structure and definition. The Test message is sent according to [RFC4204] using bit-= oriented HDLC framing format [RFC1662]. - 0x08 GCC1/2: Test Message over the GCC1/2 Capability of transmitting Test messages using the ODUk Overhead General Communications Channels (GCC1/2). See ITU G.709 Section 15.8 for the structure and definition. The Test message is sent according to [RFC4204] using bit-= oriented HDLC framing format [RFC1662]. " In the draft there is no distinguishing between transmitting the test messa= ge over GCC1 or GCC2 while the other endpoint of the link may be capable of= terminating one of them but not both. Thus I would suggest to allocate sep= arate bit for each. Best Regards, Yechiel Rosengarten System Engineering ECI Telecom Ltd 30 Hasivim St. Petach Tikva 49517 Israel e-mail: yechiel.rosengarten@ecitele.com From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of F= atai Zhang Sent: Friday, October 23, 2009 11:32 AM To: CCAMP Subject: [CCAMP] OTN control drafts Hi CCAMPers, You know that there are lots of interests from both a technical and organiz= ational standpoint (e.g., ITU-T SG15/Q12,Q14, IETF CCAMP) on OTN control, s= ince draft-zhang-ccamp-gmpls-evolving-g709-00.txt was presented in IETF 75t= h meeting. You also know that [G.709 V3] including ODU0, ODU4, ODUflex... was consente= d by ITU-T SG15 in this October. Therefore, in order to control and manage= the OTN networks efficiently, OTN control is really important for the indu= stry. Up to now, we have five drafts about OTN control: (1) draft-zhang-ccamp-gmpls-g709-framework-00.txt (2) draft-zhang-ccamp-gmpls-evolving-g709-03.txt (3) draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt (4) draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt (5) draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt To promote better understanding or the discussions in Hiroshima meeting, we= 'd appreciate your review and comments. Thanks Authors of these drafts --_000_93BC09B2B8795C49B4E3453CE6A45A18A1B27CF2A1ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

=  

From Parag= raph 3.2 of the draft:

“

3.2= = .  Verify Transport Mechanism

 = ;

 &nbs= p;    . . . . .     

 &nbs= p;    Capability of transmitting Test messages using ODUk Trail Trace<= /span>

 &nbs= p;    Identifier (TTI) overhead with frame length of 64 bytes.  See ITU=

 &nbs= p;    G.709 Section 15.2 and Section 15.8 for the structure and

 &nbs= p;    definition.  The Test message is sent according to [RFC4204].

 = ;

 &nbs= p;    - 0x04 GCC0: Test Message over the GCC0

 = ;

 &nbs= p;    Capability of transmitting Test messages using the OTUk Overhead=

 &nbs= p;    General Communications Channel (GCC0).  See ITU G.709 Section 15.7

 &nbs= p;    for the structure and definition.  The Test message is sent=

 &nbs= p;    according to [RFC4204] using bit-oriented HDLC framing format

 &nbs= p;    [RFC1662].

 = ;

 &nbs= p;    - 0x08 GCC1/2: Test Message over the GCC1/2

 = ;

 &nbs= p;    Capability of transmitting Test messages using the ODUk Overhead=

 &nbs= p;    General Communications Channels (GCC1/2).  See ITU G.709 Section<= /o:p>

 &nbs= p;    15.8 for the structure and definition.  The Test message is sent<= /o:p>

 &nbs= p;    according to [RFC4204] using bit-oriented HDLC framing format

 &nbs= p;    [RFC1662].

“

 = ;

In the dra= ft there is no distinguishing between transmitting the test message over GCC1 = or GCC2 while the other endpoint of the link may be capable of terminating one of t= hem but not both. Thus I would suggest to allocate separate bit for each. =

 = ;

Best Regards,

 

     Yechiel Rosengarten
     System Engineering
     ECI Telecom Ltd
     30 Hasivim St. Petach Tikva 49517 Israel

     e-mail: yechiel.rosengarten@ecitele.com

 

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Fatai Zhang
Sent: Friday, October 23, 2009 11:32 AM
To: CCAMP
Subject: [CCAMP] OTN control drafts

 

Hi CCAMPers,

 

You know that there are lots of interests from both a technical and organizatio= nal standpoint (e.g., ITU-T SG15/Q12,Q14, IETF CCAMP) on OTN control, since draft-zhang-ccamp-gmpls-evolving-g709-00.txt was presented in IETF 75th meeting.

 

You also know that [G.709 V3] including ODU0, ODU4, ODUflex... was consented by ITU-T SG15 in this October.  Therefore, in order to control and manage= the OTN networks efficiently, OTN control is really important for the industry.=

 

Up to now, we have five drafts about OTN control:

 

To promote better understanding or the discussions in Hiroshima meeting, we'd appreciate your review and comments.

 

 

Thanks

 

Authors of these drafts

 

 

--_000_93BC09B2B8795C49B4E3453CE6A45A18A1B27CF2A1ILPTMAIL02eci_-- From zhangfatai@huawei.com Mon Oct 26 02:36:07 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370F43A682A for ; Mon, 26 Oct 2009 02:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xliAAY5rm4Sy for ; Mon, 26 Oct 2009 02:36:05 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 407C93A6358 for ; Mon, 26 Oct 2009 02:36:05 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS400KB47ZHSU@szxga04-in.huawei.com> for ccamp@ietf.org; Mon, 26 Oct 2009 17:35:41 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS4002UJ7ZH5U@szxga04-in.huawei.com> for ccamp@ietf.org; Mon, 26 Oct 2009 17:35:41 +0800 (CST) Received: from z41162b ([10.70.76.112]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS400KHM7ZGJJ@szxml04-in.huawei.com> for ccamp@ietf.org; Mon, 26 Oct 2009 17:35:41 +0800 (CST) Date: Mon, 26 Oct 2009 17:35:40 +0800 From: Fatai Zhang To: Yechiel Rosengarten Message-id: <025a01ca561f$aea27de0$704c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_CMFYFlFqb9odmeB1MjnJZw)" X-Priority: 3 X-MSMail-priority: Normal References: <05e001ca53c3$a02e2fb0$704c460a@china.huawei.com> <93BC09B2B8795C49B4E3453CE6A45A18A1B27CF269@ILPTMAIL02.ecitele.com> Cc: CCAMP Subject: Re: [CCAMP] OTN control drafts: draft-zhang-ccamp-gmpls-g709-framework-00.txt: X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 09:36:07 -0000 This is a multi-part message in MIME format. --Boundary_(ID_CMFYFlFqb9odmeB1MjnJZw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Yechiel, Thanks for your careful review and valuable comments. I respond your questions one by one in the following: (1) ODU4 as Lo ODU This question is related to the concept of Ho ODU and Lo ODU. "The current terminology in G.709 uses the term Higher Order ODU is used to identify an ODU that carries Lower Order ODU and is carried directly over an OTU. The term Lower Order ODU is used to identify an ODU that is multiplex into a Higher Order ODU before it is carried by an OTU, or an ODU that carries a payload (other than a Lower Order ODU) and is carrier over an OTU." ---- From the meeting report of ITU-T Q12 in June 2009. So, we can understand when the ODU4 carries a 100GE service, then it is a LO ODU4. When the ODU4 carries a set of LO ODUs and the multiplexing is done in the carrier's network, then the ODU4 is a HO ODU4. (2) Why link 4# and link 5# don't support ODU1 Here is just an example (You know the fact that a Ho ODU or OTU link may not support all the types of Lo ODU signals). To be accurate and avoid confusion, I should modify the text as follows (To be updated in the next version): Link #1: Ho ODU2/OTU2, support transport of either LO ODU0 and LO ODU1 via HO ODU2/OTU2, or LO ODU2 via OTU2; Link #2: Ho ODU3/OTU3, support transport of either LO ODU0, LO ODU1, LO ODU2 via HO ODU3/OTU3, or LO ODU3 via OTU3; Link #3: Ho ODU2/OTU2, support transport of either LO ODU0, LO ODU1 via HO ODU2/OTU2, or LO ODU2 via OTU2; Link #4: Ho ODU1/OTU1, support transport of either LO ODU0 via HO ODU1/OTU1, or LO ODU1 via OTU1; Link #5: Ho ODU1/OTU1, support transport of either LO ODU0 via HO ODU1/OTU1, or LO ODU1 via OTU1; Thanks Fatai Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: Yechiel Rosengarten To: Fatai Zhang ; CCAMP Sent: Sunday, October 25, 2009 4:23 PM Subject: RE: [CCAMP] OTN control drafts: draft-zhang-ccamp-gmpls-g709-framework-00.txt: Hi, Some questions about draft-zhang-ccamp-gmpls-g709-framework-00.txt: 1. " 3.1.2.2. Optical channel data unit (ODUk) The optical channel data unit (ODUk) provides adaptation of client signals via the Optical Channel Payload Unit (OPUk) LO ODU (Lower order ODU) can be multiplexed into HO ODU (higher order ODU), which is described in section 3.2.2. Currently, the following ODUk types are defined: ODU0, ODU1, ODU2, ODU3, ODU4, ODU2e, ODUflex, ODU3e1, ODU3e2. ODUk has a bandwidth/bit rate BR and a bit rate tolerance T i.e. ODU(BR,T). The detailed bit rates and tolerance of the ODUk signals (except ODUflex) are defined in [ITUT-G709], [Gsup43] and [G709-V3]. The bitrate and tolerance of the ODUflex is dependent on the client signal. HO ODUk types are: ODU1, ODU2, ODU3, ODU4, ODU3e1, ODU3e2. LO ODUk types are: ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4, ODUflex. ODU3e1 and ODU3e2 can be treated as LO ODU signals outside the domain in which these signals terminate. " I wonder why ODU4 is included as LO ODUk type. It cannot be multiplexed to any higher order ODUk 2. " Take the following Figure 6 as an example, the single topology containing links and matrices can be illustrated as follows: LO ODU Link #1: HO ODU2, support transport of ODU0, ODU1, ODU2; LO ODU Link #2: HO ODU3, support transport of ODU0, ODU1, ODU2, ODU3; LO ODU Link #3: HO ODU2, support transport of ODU0, ODU1, ODU2; LO ODU Link #4: HO ODU1, support transport of ODU0; LO ODU Link #5: HO ODU1, support transport of ODU0; LO ODU Matrix A LO ODU Matrix B LO ODU Matrix C LO ODU Matrix D LO ODU Matrix E " Why link #4 and #5 do not support transport of ODU1? Is there any concept to do this exception compared to the other links? Best Regards, Yechiel Rosengarten System Engineering ECI Telecom Ltd e-mail: yechiel.rosengarten@ecitele.com From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Fatai Zhang Sent: Friday, October 23, 2009 11:32 AM To: CCAMP Subject: [CCAMP] OTN control drafts Hi CCAMPers, You know that there are lots of interests from both a technical and organizational standpoint (e.g., ITU-T SG15/Q12,Q14, IETF CCAMP) on OTN control, since draft-zhang-ccamp-gmpls-evolving-g709-00.txt was presented in IETF 75th meeting. You also know that [G.709 V3] including ODU0, ODU4, ODUflex... was consented by ITU-T SG15 in this October. Therefore, in order to control and manage the OTN networks efficiently, OTN control is really important for the industry. Up to now, we have five drafts about OTN control: (1) draft-zhang-ccamp-gmpls-g709-framework-00.txt (2) draft-zhang-ccamp-gmpls-evolving-g709-03.txt (3) draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt (4) draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt (5) draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt To promote better understanding or the discussions in Hiroshima meeting, we'd appreciate your review and comments. Thanks Authors of these drafts --Boundary_(ID_CMFYFlFqb9odmeB1MjnJZw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczp4ID0gDQoidXJuOnNjaGVtYXMt bWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm0gPSANCiJodHRwOi8vc2NoZW1hcy5t aWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVp dj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0K PE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjkwMC4zNjAzIiBuYW1lPUdFTkVSQVRPUj4NCjxT VFlMRT5AZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogU2ltU3VuOw0KfQ0KQGZvbnQtZmFjZSB7 DQoJZm9udC1mYW1pbHk6IFNpbVN1bjsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBD YWxpYnJpOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFRhaG9tYTsNCn0NCkBmb250 LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBAU2ltU3VuOw0KfQ0KQHBhZ2UgU2VjdGlvbjEge3NpemU6 IDYxMi4wcHQgNzkyLjBwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7IH0N ClAuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDEycHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZP TlQtRkFNSUxZOiBTaW1TdW4NCn0NCkxJLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMnB0OyBN QVJHSU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTogU2ltU3VuDQp9DQpESVYuTXNvTm9ybWFs IHsNCglGT05ULVNJWkU6IDEycHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiBT aW1TdW4NCn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJs aW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09M T1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6 IDk5DQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lOyBtc28tc3R5bGUtcHJpb3JpdHk6IDk5DQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxv d2VkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZTsgbXNvLXN0 eWxlLXByaW9yaXR5OiA5OQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUNPTE9SOiAjMWY0OTdk OyBGT05ULUZBTUlMWTogIkNhbGlicmkiLCJzYW5zLXNlcmlmIjsgbXNvLXN0eWxlLXR5cGU6IHBl cnNvbmFsLXJlcGx5DQp9DQouTXNvQ2hwRGVmYXVsdCB7DQoJRk9OVC1TSVpFOiAxMHB0OyBtc28t c3R5bGUtdHlwZTogZXhwb3J0LW9ubHkNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlv bjENCn0NCjwvU1RZTEU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+PC9IRUFEPg0KPEJPRFkgbGFuZz1FTi1VUyB2TGluaz1wdXJwbGUgbGluaz1i bHVlIGJnQ29sb3I9d2hpdGU+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+SGkmbmJzcDsgWWVjaGll bCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPlRoYW5rcyBmb3IgeW91ciBjYXJlZnVsIHJldmlldyBh bmQgdmFsdWFibGUgDQpjb21tZW50cy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPkkgcmVzcG9uZCB5 b3VyIHF1ZXN0aW9ucyBvbmUgYnkgb25lIGluIHRoZSANCmZvbGxvd2luZzo8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBm YWNlPUFyaWFsPigxKSBPRFU0IGFzIExvIE9EVTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+VGhpcyBx dWVzdGlvbiBpcyByZWxhdGVkIHRvIHRoZSBjb25jZXB0IG9mIEhvIE9EVSBhbmQgTG8gDQpPRFUu PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbD4iVGhlIGN1cnJlbnQgdGVybWlub2xvZ3kgaW4gRy43MDkg dXNlcyB0aGUgdGVybSBIaWdoZXIgDQpPcmRlciBPRFUgaXMgdXNlZCB0byBpZGVudGlmeSBhbiBP RFUgdGhhdCBjYXJyaWVzIExvd2VyIE9yZGVyIE9EVSBhbmQgaXMgY2FycmllZCANCmRpcmVjdGx5 IG92ZXIgYW4gT1RVLiZuYnNwOyBUaGUgdGVybSBMb3dlciBPcmRlciBPRFUgaXMgdXNlZCB0byBp ZGVudGlmeSBhbiBPRFUgDQp0aGF0IGlzIG11bHRpcGxleCBpbnRvIGEgSGlnaGVyIE9yZGVyIE9E VSBiZWZvcmUgaXQgaXMgY2FycmllZCBieSBhbiBPVFUsIG9yIGFuIA0KT0RVIHRoYXQgY2Fycmll cyBhIHBheWxvYWQgKG90aGVyIHRoYW4gYSBMb3dlciBPcmRlciBPRFUpIGFuZCBpcyBjYXJyaWVy IG92ZXIgYW4gDQpPVFUuIiZuYnNwOyAtLS0tIEZyb20gdGhlJm5ic3A7bWVldGluZyByZXBvcnQg b2YgSVRVLVQgUTEyIGluIEp1bmUgDQoyMDA5LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+U28sJm5i c3A7d2UgY2FuIHVuZGVyc3RhbmQgdzxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgDQpjb2xvcj0j MDAwMDAwPmhlbiB0aGUgT0RVNCBjYXJyaWVzIGEgMTAwR0Ugc2VydmljZSwgdGhlbiBpdCBpcyBh IExPIE9EVTQuIFdoZW4gDQp0aGUgT0RVNCBjYXJyaWVzIGEgc2V0IG9mIExPIE9EVXMgYW5kIHRo ZSBtdWx0aXBsZXhpbmcgaXMgZG9uZSBpbiB0aGUgY2FycmllcidzIA0KbmV0d29yaywgdGhlbiB0 aGUgT0RVNCBpcyBhIEhPIE9EVTQuIDwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bD4oMikgV2h5IGxpbmsgNCMgYW5kIGxpbmsgNSMgZG9uJ3Qgc3VwcG9ydCANCk9EVTE8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsPkhlcmUgaXMganVzdCBhbiBleGFtcGxlIChZb3Uga25vdyB0aGUgZmFj dCB0aGF0IGEgSG8gT0RVIA0Kb3IgT1RVIGxpbmsgbWF5IG5vdCBzdXBwb3J0IGFsbCB0aGUgdHlw ZXMgb2YgTG8gT0RVIHNpZ25hbHMpLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPlRvIGJlIGFjY3Vy YXRlIGFuZCBhdm9pZCBjb25mdXNpb24sIEkgc2hvdWxkIG1vZGlmeSB0aGUgDQp0ZXh0IGFzIGZv bGxvd3MgKFRvIGJlIHVwZGF0ZWQgaW4gdGhlIG5leHQgdmVyc2lvbik6PC9GT05UPjwvRElWPg0K PERJVj48U1BBTiBjbGFzcz0yODEwNDE0MDgtMjYxMDIwMDk+PEZPTlQgZmFjZT1BcmlhbD4mbmJz cDs8L0ZPTlQ+PC9ESVY+DQo8RElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xh c3M9MjgxMDQxNDA4LTI2MTAyMDA5PjxGT05UIA0KZmFjZT1BcmlhbD4mbmJzcDsmbmJzcDsgTGlu ayAjMTogSG8gT0RVMi9PVFUyLCBzdXBwb3J0IHRyYW5zcG9ydCBvZiBlaXRoZXIgTE8gDQpPRFUw IGFuZCBMTyBPRFUxIHZpYSBITyBPRFUyL09UVTIsIG9yIExPIE9EVTIgdmlhIE9UVTI7IDwvRk9O VD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTI4MTA0MTQwOC0yNjEwMjAwOT48Rk9O VCBmYWNlPUFyaWFsPiZuYnNwOyZuYnNwOyANCjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxT UEFOIGNsYXNzPTI4MTA0MTQwOC0yNjEwMjAwOT48Rk9OVCBmYWNlPUFyaWFsPiZuYnNwOyZuYnNw OyBMaW5rICMyOiBIbyANCk9EVTMvT1RVMywgc3VwcG9ydCB0cmFuc3BvcnQgb2YgZWl0aGVyIExP IE9EVTAsIExPIE9EVTEsIExPIE9EVTIgdmlhIEhPIA0KT0RVMy9PVFUzLCBvciBMTyBPRFUzIHZp YSBPVFUzOyA8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0yODEwNDE0MDgt MjYxMDIwMDk+PEZPTlQgZmFjZT1BcmlhbD4mbmJzcDsmbmJzcDsgDQo8L0ZPTlQ+PC9TUEFOPjwv RElWPg0KPERJVj48U1BBTiBjbGFzcz0yODEwNDE0MDgtMjYxMDIwMDk+PEZPTlQgZmFjZT1Bcmlh bD4mbmJzcDsmbmJzcDsgTGluayAjMzogSG8gDQpPRFUyL09UVTIsIHN1cHBvcnQgdHJhbnNwb3J0 IG9mIGVpdGhlciBMTyBPRFUwLCBMTyBPRFUxIHZpYSBITyBPRFUyL09UVTIsIG9yIExPIA0KT0RV MiB2aWEgT1RVMjsgPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48 L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz0y ODEwNDE0MDgtMjYxMDIwMDk+PEZPTlQgDQpmYWNlPUFyaWFsPiZuYnNwOyZuYnNwOyBMaW5rICM0 OiBIbyBPRFUxL09UVTEsIHN1cHBvcnQgdHJhbnNwb3J0IG9mIGVpdGhlciBMTyANCk9EVTAgdmlh IEhPIE9EVTEvT1RVMSwgb3IgTE8gT0RVMSB2aWEgT1RVMTsgPC9GT05UPjwvU1BBTj48L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIg YWxpZ249bGVmdD48U1BBTiBjbGFzcz0yODEwNDE0MDgtMjYxMDIwMDk+PEZPTlQgY29sb3I9IzAw MDBmZj48Rk9OVCANCmZhY2U9QXJpYWw+PEZPTlQgY29sb3I9IzAwMDAwMD4mbmJzcDsmbmJzcDsg TGluayAjNTogSG8gT0RVMS9PVFUxLCBzdXBwb3J0IA0KdHJhbnNwb3J0IG9mIGVpdGhlciBMTyBP RFUwIHZpYSBITyBPRFUxL09UVTEsIG9yIExPIE9EVTEgdmlhIE9UVTE7PC9GT05UPiANCjwvRk9O VD48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xh c3M9MjgxMDQxNDA4LTI2MTAyMDA5PjxGT05UIA0KZmFjZT1BcmlhbD48L0ZPTlQ+PC9TUEFOPiZu YnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MjgxMDQxNDA4 LTI2MTAyMDA5PjxGT05UIA0KZmFjZT1BcmlhbD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0K PERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MjgxMDQxNDA4LTI2MTAyMDA5PjxG T05UIA0KZmFjZT1BcmlhbD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJViBkaXI9bHRy IGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9MjgxMDQxNDA4LTI2MTAyMDA5PjxGT05UIA0KZmFjZT1B cmlhbD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPjwvU1BBTj48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+VGhh bmtzPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5GYXRhaTxCUj4mbmJzcDs8QlI+QWR2YW5jZWQgVGVj aG5vbG9neSANCkRlcGFydG1lbnQ8QlI+V2lyZWxpbmUgTmV0d29ya2luZyBCdXNpbmVzcyBVbml0 PEJSPkh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCANCkxURC48QlI+SHVhd2VpIEJhc2UsIEJhbnRp YW4sIExvbmdnYW5nLDxCUj5TaGVuemhlbiA1MTgxMjkgUC5SLkNoaW5hPEJSPlRlbDogDQorODYt NzU1LTI4OTcyOTEyPEJSPkZheDogKzg2LTc1NS0yODk3MjkzNTwvRk9OVD48L0RJVj4NCjxCTE9D S1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6 IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBN QVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAz MDc7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJC QUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OzsgZm9udC1jb2xv cjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9WWVjaGllbC5Sb3NlbmdhcnRlbkBl Y2l0ZWxlLmNvbSANCiAgaHJlZj0ibWFpbHRvOlllY2hpZWwuUm9zZW5nYXJ0ZW5AZWNpdGVsZS5j b20iPlllY2hpZWwgUm9zZW5nYXJ0ZW48L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5 cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9CPiA8QSB0aXRsZT16aGFuZ2ZhdGFpQGh1YXdl aS5jb20gDQogIGhyZWY9Im1haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb20iPkZhdGFpIFpoYW5n PC9BPiA7IDxBIHRpdGxlPWNjYW1wQGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86Y2NhbXBAaWV0 Zi5vcmciPkNDQU1QPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7 JiMyMDMwNzsiPjxCPlNlbnQ6PC9CPiBTdW5kYXksIE9jdG9iZXIgMjUsIDIwMDkgNDoyMyBQTTwv RElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U3ViamVj dDo8L0I+IFJFOiBbQ0NBTVBdIE9UTiBjb250cm9sIGRyYWZ0czogDQogIGRyYWZ0LXpoYW5nLWNj YW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAwLnR4dDo8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+ DQogIDxESVYgY2xhc3M9U2VjdGlvbjE+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48QSBuYW1lPXNl Y3Rpb24tMy4xLjIuMj48U1BBTiANCiAgbGFuZz1FTj5IaSw8bzpwPjwvbzpwPjwvU1BBTj48L0E+ PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gbGFuZz1FTj5Tb21lIHF1ZXN0aW9ucyBh Ym91dCA8L1NQQU4+PEEgDQogIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXpoYW5nLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAwLnR4dCI+PFNQQU4gDQogIHN0eWxl PSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPmRyYWZ0LXpoYW5nLWNjYW1wLWdt cGxzLWc3MDktZnJhbWV3b3JrLTAwLnR4dDwvU1BBTj48L0E+PFNQQU4gDQogIHN0eWxlPSJGT05U LUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPjo8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQog IDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwn LCdzYW5zLXNlcmlmJyI+MS48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1J TFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj6TPC9TUEFOPjxTUEFOIA0KICBsYW5nPUVOPjxvOnA+ PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVG VDogMzZwdCI+PFNQQU4gbGFuZz1FTj4zLjEuMi4yPC9TUEFOPjxTUEFOIA0KICBsYW5nPUVOPi4g T3B0aWNhbCBjaGFubmVsIGRhdGEgdW5pdCAoT0RVayk8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQog IDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxTUEFOIGxhbmc9 RU4+Jm5ic3A7Jm5ic3A7IFRoZSANCiAgb3B0aWNhbCBjaGFubmVsIGRhdGEgdW5pdCAoT0RVaykg cHJvdmlkZXMgYWRhcHRhdGlvbiBvZiANCiAgY2xpZW50PG86cD48L286cD48L1NQQU4+PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48U1BBTiBsYW5n PUVOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3 JyI+Jm5ic3A7Jm5ic3A7IHNpZ25hbHMgdmlhIA0KICB0aGUgT3B0aWNhbCBDaGFubmVsIFBheWxv YWQgVW5pdCAoT1BVaykgTE8gT0RVIChMb3dlcjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PFNQQU4gbGFuZz1FTiAN CiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPiZu YnNwOyZuYnNwOyBvcmRlciBPRFUpIA0KICBjYW4gYmUgbXVsdGlwbGV4ZWQgaW50byBITyBPRFUg KGhpZ2hlciBvcmRlciBPRFUpLCB3aGljaDxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PFNQQU4gbGFuZz1FTiANCiAg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPiZuYnNw OyZuYnNwOyBpcyBkZXNjcmliZWQgDQogIGluIDxBIA0KICBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0wMCNzZWN0 aW9uLTMuMi4yIj5zZWN0aW9uIA0KICAzLjIuMjwvQT4uPG86cD48L286cD48L1NQQU4+PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48U1BBTiBsYW5n PUVOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3 JyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48U1BBTiBsYW5nPUVOIA0KICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+Jm5ic3A7Jm5ic3A7IEN1cnJlbnRs eSwgDQogIHRoZSBmb2xsb3dpbmcgT0RVayB0eXBlcyBhcmUgZGVmaW5lZDogT0RVMCwgT0RVMSwg T0RVMiw8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0i TUFSR0lOLUxFRlQ6IDM2cHQiPjxTUEFOIGxhbmc9RU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj4mbmJzcDsmbmJzcDsgT0RVMywgT0RVNCwg DQogIE9EVTJlLCBPRFVmbGV4LCBPRFUzZTEsIE9EVTNlMi4gT0RVayBoYXMgYSBiYW5kd2lkdGgv Yml0PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B UkdJTi1MRUZUOiAzNnB0Ij48U1BBTiBsYW5nPUVOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+Jm5ic3A7Jm5ic3A7IHJhdGUgQlIgYW5kIGEg DQogIGJpdCByYXRlIHRvbGVyYW5jZSBUIGkuZS4gT0RVKEJSLFQpLiBUaGUgZGV0YWlsZWQgYml0 PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ Ti1MRUZUOiAzNnB0Ij48U1BBTiBsYW5nPUVOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+Jm5ic3A7Jm5ic3A7IHJhdGVzIGFuZCANCiAgdG9s ZXJhbmNlIG9mIHRoZSBPRFVrIHNpZ25hbHMgKGV4Y2VwdCBPRFVmbGV4KSBhcmUgDQogIGRlZmlu ZWQ8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFS R0lOLUxFRlQ6IDM2cHQiPjxTUEFOIGxhbmc9RU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj4mbmJzcDsmbmJzcDsgaW4gWzxBIA0KICB0aXRs ZT0nIkludGVyZmFjZSBmb3IgdGhlIE9wdGljYWwgVHJhbnNwb3J0IE5ldHdvcmsgKE9UTiksIicg DQogIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLWNjYW1wLWdt cGxzLWc3MDktZnJhbWV3b3JrLTAwI3JlZi1JVFVULUc3MDkiPklUVVQtRzcwOTwvQT5dLCANCiAg WzxBIHRpdGxlPSciUHJvcG9zZWQgcmV2aXNpb24gb2YgRy5zdXA0MyAoZm9yIGFncmVlbWVudCks IicgDQogIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLWNjYW1w LWdtcGxzLWc3MDktZnJhbWV3b3JrLTAwI3JlZi1Hc3VwNDMiPkdzdXA0MzwvQT5dIA0KICBhbmQg WzxBIHRpdGxlPSciRHJhZnQgcmV2aXNlZCBHLjcwOSwgdmVyc2lvbiAzLCInIA0KICBocmVmPSJo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1jY2FtcC1nbXBscy1nNzA5LWZy YW1ld29yay0wMCNyZWYtRzcwOS1WMyI+RzcwOS1WMzwvQT5dLiANCiAgVGhlIGJpdHJhdGUgYW5k IHRvbGVyYW5jZSBvZjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PFNQQU4gbGFuZz1FTiANCiAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPiZuYnNwOyZuYnNwOyB0aGUg T0RVZmxleCANCiAgaXMgZGVwZW5kZW50IG9uIHRoZSBjbGllbnQgc2lnbmFsLjxvOnA+PC9vOnA+ PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZw dCI+PFNQQU4gbGFuZz1FTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 ICdDb3VyaWVyIE5ldyciPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PFNQQU4gbGFuZz1FTiANCiAgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPiZuYnNwOyZu YnNwOyBITyBPRFVrIHR5cGVzIA0KICBhcmU6IE9EVTEsIE9EVTIsIE9EVTMsIE9EVTQsIE9EVTNl MSwgT0RVM2UyLjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PFNQQU4gbGFuZz1FTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPjxvOnA+Jm5ic3A7PC9vOnA+PC9T UEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+ PFNQQU4gbGFuZz1FTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdD b3VyaWVyIE5ldyciPiZuYnNwOyZuYnNwOyBMTyBPRFVrIHR5cGVzIA0KICBhcmU6IE9EVTAsIE9E VTEsIE9EVTIsIE9EVTJlLCBPRFUzLCBPRFU0LCBPRFVmbGV4LjxvOnA+PC9vOnA+PC9TUEFOPjwv UD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PFNQQU4g bGFuZz1FTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVy IE5ldyciPiZuYnNwOyZuYnNwOyBPRFUzZTEgYW5kIA0KICBPRFUzZTIgY2FuIGJlIHRyZWF0ZWQg YXMgTE8gT0RVIHNpZ25hbHMgb3V0c2lkZSB0aGUgZG9tYWluIGluIHdoaWNoIHRoZXNlIA0KICBz aWduYWxzIHRlcm1pbmF0ZS48bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxTUEFOIGxhbmc9RU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj6UPG86cD48L286cD48 L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0 Ij48U1BBTiBsYW5nPUVOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog J0NvdXJpZXIgTmV3JyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1N c29Ob3JtYWw+PFNQQU4gbGFuZz1FTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6ICdDb3VyaWVyIE5ldyciPkkgd29uZGVyIHdoeSBPRFU0IGlzIA0KICBpbmNsdWRlZCBh cyBMTyBPRFVrIHR5cGUuIEl0IGNhbm5vdCBiZSBtdWx0aXBsZXhlZCB0byBhbnkgaGlnaGVyIG9y ZGVyIA0KICBPRFVrPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PFNQQU4gbGFuZz1FTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdD b3VyaWVyIE5ldyciPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PFNQQU4gbGFuZz1FTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPjIuIDxvOnA+PC9v OnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDog MzZwdCI+PFNQQU4gbGFuZz1FTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6ICdDb3VyaWVyIE5ldyciPiZuYnNwOyANCiAgkzxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PFNQQU4gbGFuZz1F TiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyci PlRha2UgdGhlIGZvbGxvd2luZyBGaWd1cmUgDQogIDYgYXMgYW4gZXhhbXBsZSwgdGhlIHNpbmds ZSB0b3BvbG9neTxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PFNQQU4gbGFuZz1FTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPiZuYnNwOyZuYnNwOyBjb250YWlu aW5nIA0KICBsaW5rcyBhbmQgbWF0cmljZXMgY2FuIGJlIGlsbHVzdHJhdGVkIGFzIGZvbGxvd3M6 PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ Ti1MRUZUOiAzNnB0Ij48U1BBTiBsYW5nPUVOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48U1BBTiBsYW5n PUVOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3 JyI+Jm5ic3A7Jm5ic3A7IExPIE9EVSBMaW5rIA0KICAjMTogSE8gT0RVMiwgc3VwcG9ydCB0cmFu c3BvcnQgb2YgT0RVMCwgT0RVMSwgT0RVMjs8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxTUEFOIGxhbmc9RU4gDQog IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48bzpw PiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFS R0lOLUxFRlQ6IDM2cHQiPjxTUEFOIGxhbmc9RU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj4mbmJzcDsmbmJzcDsgTE8gT0RVIExpbmsgDQog ICMyOiBITyBPRFUzLCBzdXBwb3J0IHRyYW5zcG9ydCBvZiBPRFUwLCBPRFUxLCBPRFUyLCANCk9E VTM7PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1B UkdJTi1MRUZUOiAzNnB0Ij48U1BBTiBsYW5nPUVOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48U1BBTiBs YW5nPUVOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIg TmV3JyI+Jm5ic3A7Jm5ic3A7IExPIE9EVSBMaW5rIA0KICAjMzogSE8gT0RVMiwgc3VwcG9ydCB0 cmFuc3BvcnQgb2YgT0RVMCwgT0RVMSwgT0RVMjs8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQ IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxTUEFOIGxhbmc9RU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48 bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0i TUFSR0lOLUxFRlQ6IDM2cHQiPjxTUEFOIGxhbmc9RU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj4mbmJzcDsmbmJzcDsgTE8gT0RVIExpbmsg DQogICM0OiBITyBPRFUxLCBzdXBwb3J0IHRyYW5zcG9ydCBvZiBPRFUwOzxvOnA+PC9vOnA+PC9T UEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+ PFNQQU4gbGFuZz1FTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdD b3VyaWVyIE5ldyciPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PFNQQU4gbGFuZz1FTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPiZuYnNwOyZuYnNw OyBMTyBPRFUgTGluayANCiAgIzU6IEhPIE9EVTEsIHN1cHBvcnQgdHJhbnNwb3J0IG9mIE9EVTA7 PG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ Ti1MRUZUOiAzNnB0Ij48U1BBTiBsYW5nPUVOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48U1BBTiBsYW5n PUVOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3 JyI+Jm5ic3A7Jm5ic3A7IExPIE9EVSBNYXRyaXggDQogIEE8bzpwPjwvbzpwPjwvU1BBTj48L1A+ DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxTUEFOIGxh bmc9RU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBO ZXcnIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxTUEFOIGxhbmc9RU4gDQogIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj4mbmJzcDsmbmJzcDsgTE8gT0RV IE1hdHJpeCANCiAgQjxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PFNQQU4gbGFuZz1FTiANCiAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPjxvOnA+Jm5ic3A7PC9vOnA+ PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZw dCI+PFNQQU4gbGFuZz1FTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 ICdDb3VyaWVyIE5ldyciPiZuYnNwOyZuYnNwOyBMTyBPRFUgTWF0cml4IA0KICBDPG86cD48L286 cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAz NnB0Ij48U1BBTiBsYW5nPUVOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogJ0NvdXJpZXIgTmV3JyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48U1BBTiBsYW5nPUVOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+Jm5ic3A7 Jm5ic3A7IExPIE9EVSBNYXRyaXggDQogIEQ8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxTUEFOIGxhbmc9RU4gDQog IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48bzpw PiZuYnNwOzwvbzpwPjwvU1BBTj48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFS R0lOLUxFRlQ6IDM2cHQiPjxTUEFOIGxhbmc9RU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj4mbmJzcDsmbmJzcDsgTE8gT0RVIE1hdHJpeCAN CiAgRTxvOnA+PC9vOnA+PC9TUEFOPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJN QVJHSU4tTEVGVDogMzZwdCI+PFNQQU4gbGFuZz1FTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPpM8bzpwPjwvbzpwPjwvU1BBTj48L1A+DQog IDxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiBsYW5nPUVOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JyI+V2h5IGxpbmsgIzQgYW5kICM1IGRvIG5v dCANCiAgc3VwcG9ydCB0cmFuc3BvcnQgb2YgT0RVMT8gSXMgdGhlcmUgYW55IGNvbmNlcHQgdG8g ZG8gdGhpcyBleGNlcHRpb24gY29tcGFyZWQgDQogIHRvIHRoZSBvdGhlciBsaW5rcz8gPG86cD48 L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDExcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdz YW5zLXNlcmlmJyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KICA8RElWPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAj MWY0OTdkOyBGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPkJlc3QgDQogIFJlZ2Fy ZHMsPG86cD48L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgZGlyPXJ0bCAN CiAgc3R5bGU9IkRJUkVDVElPTjogcnRsOyB1bmljb2RlLWJpZGk6IGVtYmVkOyBURVhULUFMSUdO OiByaWdodCI+PFNQQU4gZGlyPWx0ciANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6 ICMxZjQ5N2Q7IEZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+PG86cD4mbmJzcDs8 L286cD48L1NQQU4+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fu cy1zZXJpZiciPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgWWVjaGllbCBSb3NlbmdhcnRl bjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU3lzdGVtIA0KICBFbmdpbmVlcmluZzxCUj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRUNJIFRlbGVjb20gDQogIEx0ZDxCUj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZS1tYWlsOiA8L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJDT0xPUjogIzFm NDk3ZDsgRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj48QSANCiAgaHJlZj0ibWFp bHRvOnllY2hpZWwucm9zZW5nYXJ0ZW5AZWNpdGVsZS5jb20iPjxTUEFOIA0KICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0Ij55ZWNoaWVsLnJvc2VuZ2FydGVuQGVjaXRlbGUuY29tPC9TUEFOPjwvQT48 L1NQQU4+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDExcHQ7IENPTE9SOiAjMWY0OTdkOyBG T05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJyI+PG86cD48L286cD48L1NQQU4+PC9Q PjwvRElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6 IDExcHQ7IENPTE9SOiAjMWY0OTdkOyBGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlm JyI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9QPg0KICA8RElWPg0KICA8RElWIA0KICBzdHls ZT0iQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1SSUdIVDogMGNtOyBCT1JERVIt VE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgUEFERElORy1MRUZUOiAwY207IFBBRERJTkctQk9UVE9N OiAwY207IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdDsgQk9SREVS LUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJ Ti1MRUZUOiAzNnB0Ij48Qj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJyI+RnJvbTo8L1NQQU4+PC9CPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYn Ij4gDQogIGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYu b3JnXSA8Qj5PbiBCZWhhbGYgT2YgDQogIDwvQj5GYXRhaSBaaGFuZzxCUj48Qj5TZW50OjwvQj4g RnJpZGF5LCBPY3RvYmVyIDIzLCAyMDA5IDExOjMyIA0KICBBTTxCUj48Qj5Ubzo8L0I+IENDQU1Q PEJSPjxCPlN1YmplY3Q6PC9CPiBbQ0NBTVBdIE9UTiBjb250cm9sIA0KICBkcmFmdHM8bzpwPjwv bzpwPjwvU1BBTj48L1A+PC9ESVY+PC9ESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0i TUFSR0lOLUxFRlQ6IDM2cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9QPg0KICA8RElWPg0KICA8RElW Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48U1BBTiAN CiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+SGkgDQogIENDQU1Q ZXJzLDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZB TUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvUD48 L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDog MzZwdCI+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZici PllvdSBrbm93IHRoYXQgdGhlcmUgYXJlIGxvdHMgb2YgDQogIGludGVyZXN0cyBmcm9tIGJvdGgg YSB0ZWNobmljYWwgYW5kIG9yZ2FuaXphdGlvbmFsIHN0YW5kcG9pbnQgKGUuZy4sIElUVS1UIA0K ICBTRzE1L1ExMixRMTQsIElFVEYgQ0NBTVApIG9uIE9UTiBjb250cm9sLCBzaW5jZSANCiAgZHJh ZnQtemhhbmctY2NhbXAtZ21wbHMtZXZvbHZpbmctZzcwOS0wMC50eHQgd2FzIHByZXNlbnRlZCBp biBJRVRGIDc1dGggDQogIG1lZXRpbmcuPG86cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICA8 RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48U1BB TiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJyI+Jm5ic3A7PG86 cD48L286cD48L1NQQU4+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAn QXJpYWwnLCdzYW5zLXNlcmlmJyI+WW91IGFsc28ga25vdyB0aGF0IFtHLjcwOSBWM10gDQogIGlu Y2x1ZGluZyBPRFUwLCBPRFU0LCBPRFVmbGV4Li4uIHdhcyBjb25zZW50ZWQgYnkgSVRVLVQgU0cx NSBpbiB0aGlzIA0KICBPY3RvYmVyLiZuYnNwOyBUaGVyZWZvcmUsIGluIG9yZGVyIHRvIGNvbnRy b2wgYW5kIG1hbmFnZSB0aGUgT1ROIG5ldHdvcmtzIA0KICBlZmZpY2llbnRseSwgT1ROIGNvbnRy b2wgaXMgcmVhbGx5IGltcG9ydGFudCBmb3IgdGhlIA0KICBpbmR1c3RyeS48bzpwPjwvbzpwPjwv U1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFS R0lOLUxFRlQ6IDM2cHQiPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3Nh bnMtc2VyaWYnIj4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQog IDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5VcCB0byBub3csIHdlIGhh dmUgZml2ZSBkcmFmdHMgYWJvdXQgDQogIE9UTiBjb250cm9sOjxvOnA+PC9vOnA+PC9TUEFOPjwv UD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVG VDogMzZwdCI+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJp ZiciPigxKSA8QSANCiAgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhh bmctY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDAudHh0Ij5kcmFmdC16aGFuZy1jY2FtcC1n bXBscy1nNzA5LWZyYW1ld29yay0wMC50eHQ8L0E+IA0KICA8bzpwPjwvbzpwPjwvU1BBTj48L1A+ PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6 IDM2cHQiPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYn Ij4oMikgPEEgDQogIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5n LWNjYW1wLWdtcGxzLWV2b2x2aW5nLWc3MDktMDMudHh0Ij5kcmFmdC16aGFuZy1jY2FtcC1nbXBs cy1ldm9sdmluZy1nNzA5LTAzLnR4dDwvQT4gDQogIDxvOnA+PC9vOnA+PC9TUEFOPjwvUD48L0RJ Vj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJNQVJHSU4tTEVGVDogMzZw dCI+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ0FyaWFsJywnc2Fucy1zZXJpZiciPigz KSA8QSANCiAgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2VjY2FyZWxs aS1jY2FtcC1nbXBscy1vc3BmLWc3MDktMDAudHh0Ij5kcmFmdC1jZWNjYXJlbGxpLWNjYW1wLWdt cGxzLW9zcGYtZzcwOS0wMC50eHQ8L0E+IA0KICA8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+ DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQi PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj4oNCkg PEEgDQogIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNlY2NhcmVsbGkt Y2NhbXAtZ21wbHMtZzcwOS1sbXAtdGVzdC0wMS50eHQiPmRyYWZ0LWNlY2NhcmVsbGktY2NhbXAt Z21wbHMtZzcwOS1sbXAtdGVzdC0wMS50eHQ8L0E+IA0KICA8bzpwPjwvbzpwPjwvU1BBTj48L1A+ PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6 IDM2cHQiPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYn Ij4oNSkgPEEgDQogIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5n LWNjYW1wLWdtcGxzLWc3MDktbG1wLWRpc2NvdmVyeS0wMi50eHQiPmRyYWZ0LXpoYW5nLWNjYW1w LWdtcGxzLWc3MDktbG1wLWRpc2NvdmVyeS0wMi50eHQgDQogIDwvQT48bzpwPjwvbzpwPjwvU1BB Tj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lO LUxFRlQ6IDM2cHQiPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMt c2VyaWYnIj4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQ IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1GQU1JTFk6ICdBcmlhbCcsJ3NhbnMtc2VyaWYnIj5UbyBwcm9tb3RlIGJldHRlciB1 bmRlcnN0YW5kaW5nIG9yIA0KICB0aGUgZGlzY3Vzc2lvbnMgaW4gSGlyb3NoaW1hIG1lZXRpbmcs IHdlJ2QgYXBwcmVjaWF0ZSB5b3VyIHJldmlldyBhbmQgDQogIGNvbW1lbnRzLjxvOnA+PC9vOnA+ PC9TUEFOPjwvUD48L0RJVj48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+Jm5ic3A7PG86cD48L286cD48L1A+PC9ESVY+DQogIDxE SVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDM2cHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij48U1BBTiANCiAgc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJp YWwnLCdzYW5zLXNlcmlmJyI+VGhhbmtzPC9TUEFOPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICA8 RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1MRUZUOiAzNnB0Ij4mbmJz cDs8bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+PFNQQU4gDQogIHN0eWxlPSJGT05ULUZBTUlMWTogJ0Fy aWFsJywnc2Fucy1zZXJpZiciPkF1dGhvcnMgb2YgdGhlc2UgDQogIGRyYWZ0czwvU1BBTj48bzpw PjwvbzpwPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJN QVJHSU4tTEVGVDogMzZwdCI+Jm5ic3A7PG86cD48L286cD48L1A+PC9ESVY+DQogIDxESVY+DQog IDxQIGNsYXNzPU1zb05vcm1hbCANCnN0eWxlPSJNQVJHSU4tTEVGVDogMzZwdCI+Jm5ic3A7PG86 cD48L286cD48L1A+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_CMFYFlFqb9odmeB1MjnJZw)-- From Yechiel.Rosengarten@ecitele.com Mon Oct 26 05:10:59 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3535F3A67AB for ; Mon, 26 Oct 2009 05:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35fdXY+p8irl for ; Mon, 26 Oct 2009 05:10:49 -0700 (PDT) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id DA16F3A6945 for ; Mon, 26 Oct 2009 05:10:47 -0700 (PDT) Received: from ilptexfe.ecitele.com (HELO ilptexch01.ecitele.com) ([172.31.244.40]) by ilptiron01.ecitele.com with ESMTP; 26 Oct 2009 14:02:01 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ilptexch01.ecitele.com ([172.31.244.40]) with mapi; Mon, 26 Oct 2009 14:10:56 +0200 From: Yechiel Rosengarten To: Fatai Zhang Date: Mon, 26 Oct 2009 14:10:27 +0200 Thread-Topic: [CCAMP] OTN control drafts: draft-zhang-ccamp-gmpls-g709-framework-00.txt: Thread-Index: AcpWH8oGI0HoRFtGTy2/vMaBzew6PwAFXC+g Message-ID: <93BC09B2B8795C49B4E3453CE6A45A18A1B27CF6B1@ILPTMAIL02.ecitele.com> References: <05e001ca53c3$a02e2fb0$704c460a@china.huawei.com> <93BC09B2B8795C49B4E3453CE6A45A18A1B27CF269@ILPTMAIL02.ecitele.com> <025a01ca561f$aea27de0$704c460a@china.huawei.com> In-Reply-To: <025a01ca561f$aea27de0$704c460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_93BC09B2B8795C49B4E3453CE6A45A18A1B27CF6B1ILPTMAIL02eci_" MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] OTN control drafts: draft-zhang-ccamp-gmpls-g709-framework-00.txt: X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 12:10:59 -0000 --_000_93BC09B2B8795C49B4E3453CE6A45A18A1B27CF6B1ILPTMAIL02eci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fatai I appreciate your prompt answer Best Regards, Yechiel From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Monday, October 26, 2009 11:36 AM To: Yechiel Rosengarten Cc: CCAMP Subject: Re: [CCAMP] OTN control drafts: draft-zhang-ccamp-gmpls-g709-frame= work-00.txt: Hi Yechiel, Thanks for your careful review and valuable comments. I respond your questions one by one in the following: (1) ODU4 as Lo ODU This question is related to the concept of Ho ODU and Lo ODU. "The current terminology in G.709 uses the term Higher Order ODU is used to= identify an ODU that carries Lower Order ODU and is carried directly over = an OTU. The term Lower Order ODU is used to identify an ODU that is multip= lex into a Higher Order ODU before it is carried by an OTU, or an ODU that = carries a payload (other than a Lower Order ODU) and is carrier over an OTU= ." ---- From the meeting report of ITU-T Q12 in June 2009. So, we can understand when the ODU4 carries a 100GE service, then it is a L= O ODU4. When the ODU4 carries a set of LO ODUs and the multiplexing is done= in the carrier's network, then the ODU4 is a HO ODU4. (2) Why link 4# and link 5# don't support ODU1 Here is just an example (You know the fact that a Ho ODU or OTU link may no= t support all the types of Lo ODU signals). To be accurate and avoid confusion, I should modify the text as follows (To= be updated in the next version): Link #1: Ho ODU2/OTU2, support transport of either LO ODU0 and LO ODU1 v= ia HO ODU2/OTU2, or LO ODU2 via OTU2; Link #2: Ho ODU3/OTU3, support transport of either LO ODU0, LO ODU1, LO = ODU2 via HO ODU3/OTU3, or LO ODU3 via OTU3; Link #3: Ho ODU2/OTU2, support transport of either LO ODU0, LO ODU1 via = HO ODU2/OTU2, or LO ODU2 via OTU2; Link #4: Ho ODU1/OTU1, support transport of either LO ODU0 via HO ODU1/O= TU1, or LO ODU1 via OTU1; Link #5: Ho ODU1/OTU1, support transport of either LO ODU0 via HO ODU1/O= TU1, or LO ODU1 via OTU1; Thanks Fatai Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: Yechiel Rosengarten To: Fatai Zhang ; CCAMP Sent: Sunday, October 25, 2009 4:23 PM Subject: RE: [CCAMP] OTN control drafts: draft-zhang-ccamp-gmpls-g709-frame= work-00.txt: Hi, Some questions about draft-zhang-ccamp-gmpls-g709-framework-00.txt: 1. " 3.1.2.2. Optical channel data unit (ODUk) The optical channel data unit (ODUk) provides adaptation of client signals via the Optical Channel Payload Unit (OPUk) LO ODU (Lower order ODU) can be multiplexed into HO ODU (higher order ODU), which is described in section 3.2.2. Currently, the following ODUk types are defined: ODU0, ODU1, ODU2, ODU3, ODU4, ODU2e, ODUflex, ODU3e1, ODU3e2. ODUk has a bandwidth/bit rate BR and a bit rate tolerance T i.e. ODU(BR,T). The detailed bit rates and tolerance of the ODUk signals (except ODUflex) are defined in [ITUT-G709], [Gsup43] and [G709-V3]. The bitrat= e and tolerance of the ODUflex is dependent on the client signal. HO ODUk types are: ODU1, ODU2, ODU3, ODU4, ODU3e1, ODU3e2. LO ODUk types are: ODU0, ODU1, ODU2, ODU2e, ODU3, ODU4, ODUflex. ODU3e1 and ODU3e2 can be treated as LO ODU signals outside the domain in= which these signals terminate. " I wonder why ODU4 is included as LO ODUk type. It cannot be multiplexed to = any higher order ODUk 2. " Take the following Figure 6 as an example, the single topology containing links and matrices can be illustrated as follows: LO ODU Link #1: HO ODU2, support transport of ODU0, ODU1, ODU2; LO ODU Link #2: HO ODU3, support transport of ODU0, ODU1, ODU2, ODU3; LO ODU Link #3: HO ODU2, support transport of ODU0, ODU1, ODU2; LO ODU Link #4: HO ODU1, support transport of ODU0; LO ODU Link #5: HO ODU1, support transport of ODU0; LO ODU Matrix A LO ODU Matrix B LO ODU Matrix C LO ODU Matrix D LO ODU Matrix E " Why link #4 and #5 do not support transport of ODU1? Is there any concept t= o do this exception compared to the other links? Best Regards, Yechiel Rosengarten System Engineering ECI Telecom Ltd e-mail: yechiel.rosengarten@ecitele.com From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of F= atai Zhang Sent: Friday, October 23, 2009 11:32 AM To: CCAMP Subject: [CCAMP] OTN control drafts Hi CCAMPers, You know that there are lots of interests from both a technical and organiz= ational standpoint (e.g., ITU-T SG15/Q12,Q14, IETF CCAMP) on OTN control, s= ince draft-zhang-ccamp-gmpls-evolving-g709-00.txt was presented in IETF 75t= h meeting. You also know that [G.709 V3] including ODU0, ODU4, ODUflex... was consente= d by ITU-T SG15 in this October. Therefore, in order to control and manage= the OTN networks efficiently, OTN control is really important for the indu= stry. Up to now, we have five drafts about OTN control: (1) draft-zhang-ccamp-gmpls-g709-framework-00.txt (2) draft-zhang-ccamp-gmpls-evolving-g709-03.txt (3) draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt (4) draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt (5) draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt To promote better understanding or the discussions in Hiroshima meeting, we= 'd appreciate your review and comments. Thanks Authors of these drafts --_000_93BC09B2B8795C49B4E3453CE6A45A18A1B27CF6B1ILPTMAIL02eci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Fatai

I appreciate your prompt answer

 

Best Regards,

 

     Yechiel

 

From: Fatai Zhang [mailto:zhangfatai@huawei.c= om]
Sent: Monday, October 26, 2009 11:36 AM
To: Yechiel Rosengarten
Cc: CCAMP
Subject: Re: [CCAMP] OTN control drafts: draft-zhang-ccamp-gmpls-g709-framework-00.txt:

 

Hi  Yechiel,<= /o:p>

 

Thanks for your careful review and valuable comments.

 

I respond your questions one by one in the following:

 

(1) ODU4 as Lo ODU=

 

This question is related to the concept of Ho ODU and Lo ODU.

 

"The current terminology in G.709 uses the term Higher Order ODU is used to iden= tify an ODU that carries Lower Order ODU and is carried directly over an OTU.&nb= sp; The term Lower Order ODU is used to identify an ODU that is multiplex into = a Higher Order ODU before it is carried by an OTU, or an ODU that carries a payload (other than a Lower Order ODU) and is carrier over an OTU."&nb= sp; ---- From the meeting report of ITU-T Q12 in June 2009.

 

So, we can understand when the ODU4 carries a 100GE se= rvice, then it is a LO ODU4. When the ODU4 carries a set of LO ODUs and the multiplexing is done in the carrier's network, then the ODU4 is a HO ODU4. =

 

(2) Why link 4# and link 5# don't support ODU1

 

Here is just an example (You know the fact that a Ho ODU or OTU link may not sup= port all the types of Lo ODU signals).

 

To be accurate and avoid confusion, I should modify the text as follows (To be updated in the next version):

 

   Link #1: Ho ODU2/OTU2, support transport of either LO ODU0 and LO ODU1 via = HO ODU2/OTU2, or LO ODU2 via OTU2;

  

   Link #2: Ho ODU3/OTU3, support transport of either LO ODU0, LO ODU1, LO ODU= 2 via HO ODU3/OTU3, or LO ODU3 via OTU3;

  

   Link #3: Ho ODU2/OTU2, support transport of either LO ODU0, LO ODU1 via HO ODU2/OTU2, or LO ODU2 via OTU2;

 

   Link #4: Ho ODU1/OTU1, support transport of either LO ODU0 via HO ODU1/OTU1= , or LO ODU1 via OTU1;

 

   Link #5: Ho ODU1/OTU1, support transport of eithe= r LO ODU0 via HO ODU1/OTU1, or LO ODU1 via OTU1;

 

 

 

 

 

Thanks

 

Fatai
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

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

Sent: Sunday, October 25, 2009 4:23 PM

Subject: RE: [CCAMP] OTN control drafts: draft-zhang-ccamp-gmpls-g709-framework-00.txt:

 

Hi,

Some ques= tions about draft-zhang-ccamp-gmpls-g709-fra= mework-00.txt:

1.

“

3.1.2.2. = Optical channel data unit (ODUk)

 &nb= sp; The optical channel data unit (ODUk) provides adaptation of client

   signals via the Optical Chan= nel Payload Unit (OPUk) LO ODU (Lower

   order ODU) can be multiplexe= d into HO ODU (higher order ODU), which

   is described in section 3.2.2.

 

   Currently, the following ODU= k types are defined: ODU0, ODU1, ODU2,

   ODU3, ODU4, ODU2e, ODUflex, ODU3e1, ODU3e2. ODUk has a bandwidth/bit

   rate BR and a bit rate toler= ance T i.e. ODU(BR,T). The detailed bit

   rates and tolerance of the O= DUk signals (except ODUflex) are defined

   in [IT= UT-G709], [Gsup43<= /a>] and [G709-V3]. The bit= rate and tolerance of

   the ODUflex is dependent on = the client signal.

 

   HO ODUk types are: ODU1, ODU= 2, ODU3, ODU4, ODU3e1, ODU3e2.

 

   LO ODUk types are: ODU0, ODU= 1, ODU2, ODU2e, ODU3, ODU4, ODUflex.

   ODU3e1 and ODU3e2 can be tre= ated as LO ODU signals outside the domain in which these signals terminate.=

”

 

I wonder why ODU4 is included as LO ODUk type. It cannot be multiplexed to any higher order ODUk

 

2.

  “

Take the following Figure 6 as an example= , the single topology

   containing links and matrice= s can be illustrated as follows:

 

   LO ODU Link #1: HO ODU2, sup= port transport of ODU0, ODU1, ODU2;

 

   LO ODU Link #2: HO ODU3, sup= port transport of ODU0, ODU1, ODU2, ODU3;

 

   LO ODU Link #3: HO ODU2, sup= port transport of ODU0, ODU1, ODU2;

 

   LO ODU Link #4: HO ODU1, sup= port transport of ODU0;

 

   LO ODU Link #5: HO ODU1, sup= port transport of ODU0;

 

   LO ODU Matrix A

 

   LO ODU Matrix B

 

   LO ODU Matrix C

 

   LO ODU Matrix D

 

   LO ODU Matrix E

“

Why link #4 and #5 do not support transpo= rt of ODU1? Is there any concept to do this exception compared to the other li= nks?

 <= /p>

Best Regards,

 

     Yechiel Rosengarten
     System Engineering
     ECI Telecom Ltd
     e-mail: yechiel.rosengarten@ecitele.com

 <= /p>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Fatai Zhang
Sent: Friday, October 23, 2009 11:32 AM
To: CCAMP
Subject: [CCAMP] OTN control drafts

 

Hi CCAMPers,

 

You know that there are lots of interests from both a technical and organizatio= nal standpoint (e.g., ITU-T SG15/Q12,Q14, IETF CCAMP) on OTN control, since draft-zhang-ccamp-gmpls-evolving-g709-00.txt was presented in IETF 75th meeting.

 

You also know that [G.709 V3] including ODU0, ODU4, ODUflex... was consented by ITU-T SG15 in this October.  Therefore, in order to control and manage= the OTN networks efficiently, OTN control is really important for the industry.=

 

Up to now, we have five drafts about OTN control:

 

To promote better understanding or the discussions in Hiroshima meeting, we'd appreciate your review and comments.

 

 

Thanks

 

Authors of these drafts

 

 

--_000_93BC09B2B8795C49B4E3453CE6A45A18A1B27CF6B1ILPTMAIL02eci_-- From zhangfatai@huawei.com Mon Oct 26 05:55:44 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 066D83A6860 for ; Mon, 26 Oct 2009 05:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.898 X-Spam-Level: X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_92=0.6, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXDJQun+MBM0 for ; Mon, 26 Oct 2009 05:55:42 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id DE0DA3A6802 for ; Mon, 26 Oct 2009 05:55:39 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS400F73H93Z7@szxga03-in.huawei.com> for ccamp@ietf.org; Mon, 26 Oct 2009 20:55:51 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS4000H5H93P1@szxga03-in.huawei.com> for ccamp@ietf.org; Mon, 26 Oct 2009 20:55:51 +0800 (CST) Received: from z41162b ([10.70.76.112]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS400EQ9H90HT@szxml04-in.huawei.com> for ccamp@ietf.org; Mon, 26 Oct 2009 20:55:51 +0800 (CST) Date: Mon, 26 Oct 2009 20:55:48 +0800 From: Fatai Zhang To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" Message-id: <04bb01ca563b$a414db90$704c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_aw1xSv/K8/GstHSrCzHRvA)" X-Priority: 3 X-MSMail-priority: Normal References: <077E41CFFD002C4CAB7DFA4386A532640167C3E9@DEMUEXC014.nsn-intra.net> <465531011AE4654BA0D30D01AB9EAA6E449EB8@FIESEXC030.nsn-intra.net> <328B9F5068825A48A4B8422A350B9047BC9D1E@CNBEEXC006.nsn-intra.net> <077E41CFFD002C4CAB7DFA4386A53264016B2EC2@DEMUEXC014.nsn-intra.net> <465531011AE4654BA0D30D01AB9EAA6E44A127@FIESEXC030.nsn-intra.net> <077E41CFFD002C4CAB7DFA4386A53264016DE8D7@DEMUEXC014.nsn-intra.net> <04c101ca53b4$1164ae30$704c460a@china.huawei.com> <077E41CFFD002C4CAB7DFA4386A532640170D04C@DEMUEXC014.nsn-intra.net> Cc: "Clemens, Rainer \(NSN - DE/Munich\)" , "Soininen, Jonne \(NSN - FI/Espoo\)" , CCAMP Subject: Re: [CCAMP] I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 12:55:44 -0000 This is a multi-part message in MIME format. --Boundary_(ID_aw1xSv/K8/GstHSrCzHRvA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Nurit, Thanks for your further comments. We think we can move the content of G.sup43 to an appendix ( just for information), and explain that this part of information is not consented by ITU-T SG15. We can also remove this appendix later, if this draft is ready to be RFC and the content of G.sup43 is still not consented (i.e., non-standard). Is it OK for you? :-)~~~~, If Yes, we will reflect it in the next version. Thanks Fatai Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) To: ext Fatai Zhang Cc: Clemens, Rainer (NSN - DE/Munich) ; CCAMP ; Soininen, Jonne (NSN - FI/Espoo) ; Li Dan ; han jianrui ; lihan@chinamobile.com Sent: Friday, October 23, 2009 9:40 PM Subject: RE: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt Hi Fatai, Thanks for your response. Referring to a document which is not a standard is problematic and even confusing. I am not sure that all the IETF colleagues could realize that a supplement document in the ITU-T is not considered as a standard. As you agreed below, G.Sup43 is NOT a standard. I believe it is NOT in the scope of CCAMP to define the dataplane behavior of ODU switching.we can define a control plane for a standard dataplane and refer to the dataplane standard behavior. Once (and if) it is defined as a standard behavior in the ITU-T, there will be room to specify an extension for GMPLS (if necessary) to support it. Also, I would like to note that it was NEVER discussed in SG1/Q11 to allow other mappings than ODU2e into ODU3e. It was even explicitly stated that no other mapping should be described in G.Sup43. The WP3 report from the plenary in December 2008 states that :"After discussion, the agreement was reached to document two versions of ODU3e, one based on the Huawei and CMCC proposal (using the eventual GMP chosen for ODU4) and the other based on the NTT and Japan proposals. Agreement was reached to only document the mapping of four 10GBASE-R clients into each of these two versions of ODU3e in an updated G.Sup43.". Nevertheless, even if specified in G.Sup43, we need to keep in mind that this is NOT a standard and we cannot refer to it as such. Best regards, Nurit ------------------------------------------------------------------------------ From: ext Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Friday, October 23, 2009 9:40 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: Clemens, Rainer (NSN - DE/Munich); CCAMP; Soininen, Jonne (NSN - FI/Espoo); Li Dan; han jianrui; lihan@chinamobile.com Subject: Re: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt Hi Nurit, Thanks for your comments. Please see below for in-line responses. Thanks Fatai Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message ----- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) To: zhangfatai@huawei.com ; danli@huawei.com ; hanjianrui@huawei.com ; lihan@chinamobile.com Cc: Clemens, Rainer (NSN - DE/Munich) ; ccamp@ietf.org ; Soininen, Jonne (NSN - FI/Espoo) Sent: Thursday, October 22, 2009 1:42 AM Subject: RE: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt Dear authors, Thanks for submitting your document on "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks". We have reviewed the document and we are a little bit concerned to find out that some significant items described in the document are not aligned with what is defined in G.709. Especially the mappings into ODU3e1 and ODU3e2 are only defined in G.Sup43 which is not a standard. In addition G.Sup43 does not define mappings of ODU0, ODU1, ODU2 and ODUflex into ODU3e2. The only mappings that are defined in G.Sup43 are 4x ODU2e. [Fatai] Yes, you are right and we also indicated in this draft that ODU3e1 and ODU3e2 are defined in G.Sup43. You know G.Sup is not standard currently,so I think we have some options for this. (1)add a note to explain that ODU3e1 and ODU3e2 are still non-standard explicitly (2) change the title of this draft to "Framework for GMPLS and PCE Control of Optical Transport Networks" (3) move ODU3e2 to an appendix. In addition, I think we can cover ODU3e1 and ODU3e2 in this draft at this stage (i.e., individual draft), because they are being developed in ITU-T and may be accepted by ITU-T some day. I will reflect this in the next version. We are afraid that this is not inline with the view of the majority of participants in SG15/Q11. [Fatai] I don't know whether it is true or not. But I think we can hear the opinions from SG15/Q11. Except of the extensions that are already described in two draft (draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn, draft-zhang-ccamp-gmpls-evolving-g709), all other content of section 3, 4 is copied from ITU standards. Would not it be better to just refer to the ITU-T document? [Fatai] In Section 3, some part of information is from G.709 and G.872 and we reference this recommendations explicitly. We just try to give a brief overview of OTN to CCAMP experts from the perspective of Control Plane and make everyone quickly understand why we need more considerations on OTN control. I think it is really tough for everyone to go through G.709, G.872 and other recommendations detailedly. As for Section 4, I don't know why you said that it is copied from ITU standards. In Section 4, it describes the connection management model for OTN networks, which is based on our understanding and some discussions in ITU-T Q12. Best regards, Nurit > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext > Internet-Drafts@ietf.org > Sent: Friday, October 16, 2009 11:45 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > Title : Framework for GMPLS and PCE Control > of G.709 Optical Transport Networks > Author(s) : F. Zhang, et al. > Filename : draft-zhang-ccamp-gmpls-g709-framework-00.txt > Pages : 27 > Date : 2009-10-16 > > This document provides a framework for applying Generalized Mulit- > Protocol Label Switching (GMPLS) and the Path Computation Element > (PCE) architecture to the control of G.709 Optical Transport Networks > (OTN) as specified in the ITU-T G.709 recommendation, including the > enhanced functionality in the recently consented revision. > > > > > zhang > > > > > > Expires April 2010 > > > > > > [page 1] > > draft-zhang-ccamp-gmpls-g709-framework-00.txt > > > > October 2009 > > > Conventions used in this document > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zhang-ccamp-gmpls-g7 > 09-framework-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > --Boundary_(ID_aw1xSv/K8/GstHSrCzHRvA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczpwID0gDQoidXJuOnNjaGVtYXMt bWljcm9zb2Z0LWNvbTpvZmZpY2U6cG93ZXJwb2ludCIgeG1sbnM6b2EgPSANCiJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOm9mZmljZTphY3RpdmF0aW9uIj48SEVBRD4NCjxNRVRBIGh0dHAtZXF1 aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4N CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI5MDAuMzYwMyIgbmFtZT1HRU5FUkFUT1I+PCEt LVtpZiAhbXNvXT4NCjxTVFlMRT52XDoqIHsNCglCRUhBVklPUjogdXJsKCNkZWZhdWx0I1ZNTCkN Cn0NCm9cOiogew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1bHQjVk1MKQ0KfQ0Kd1w6KiB7DQoJQkVI QVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQouc2hhcGUgew0KCUJFSEFWSU9SOiB1cmwoI2Rl ZmF1bHQjVk1MKQ0KfQ0KPC9TVFlMRT4NCjwhW2VuZGlmXS0tPg0KPFNUWUxFPg0KPCEtLQ0KIC8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAx O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxp Lk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6bmF2eTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpBcmlhbDsNCgljb2xv cjpuYXZ5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzcuOTVwdCA3Mi4wcHQgNzcuOTVwdDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpT ZWN0aW9uMTt9DQotLT4NCjwvU1RZTEU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9IRUFEPg0KPEJPRFkgbGFuZz1FTi1VUyB2TGluaz1wdXJw bGUgbGluaz1ibHVlIGJnQ29sb3I9d2hpdGU+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+SGkgTnVy aXQsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD5UaGFua3MgZm9yIHlvdXIgZnVydGhlciBjb21tZW50 cy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPldlJm5ic3A7dGhpbmsmbmJzcDt3ZSBjYW4mbmJzcDtt b3ZlIHRoZSBjb250ZW50IG9mIEcuc3VwNDMgDQp0byBhbiBhcHBlbmRpeCAoJm5ic3A7anVzdCBm b3IgaW5mb3JtYXRpb24pLCBhbmQgZXhwbGFpbiB0aGF0IHRoaXMgcGFydCBvZiANCmluZm9ybWF0 aW9uIGlzIG5vdCBjb25zZW50ZWQgYnkgSVRVLVQgU0cxNS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs PldlIGNhbiBhbHNvIHJlbW92ZSB0aGlzIGFwcGVuZGl4IGxhdGVyLCBpZiB0aGlzIGRyYWZ0IGlz IA0KcmVhZHkgdG8gYmUgUkZDIGFuZCB0aGUgY29udGVudCBvZiBHLnN1cDQzIGlzIHN0aWxsIG5v dCBjb25zZW50ZWQgKGkuZS4sIA0Kbm9uLXN0YW5kYXJkKS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGZhY2U9QXJpYWw+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs PklzIGl0IE9LIGZvciB5b3U/IDotKX5+fn4sIElmIFllcywgd2Ugd2lsbCByZWZsZWN0IGl0IGlu IA0KdGhlIG5leHQgdmVyc2lvbi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWw+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPlRo YW5rczwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+RmF0YWk8QlI+Jm5ic3A7PEJSPkFkdmFuY2VkIFRlY2hub2xvZ3kgRGVwYXJ0bWVudDxCUj5X aXJlbGluZSBOZXR3b3JraW5nIA0KQnVzaW5lc3MgVW5pdDxCUj5IdWF3ZWkgVGVjaG5vbG9naWVz IENvLiwgTFRELjxCUj5IdWF3ZWkgQmFzZSwgQmFudGlhbiwgDQpMb25nZ2FuZyw8QlI+U2hlbnpo ZW4gNTE4MTI5IFAuUi5DaGluYTxCUj5UZWw6ICs4Ni03NTUtMjg5NzI5MTI8QlI+RmF4OiANCis4 Ni03NTUtMjg5NzI5MzU8L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElO Ry1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVS LUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5 bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQg JiMyMzQzNTsmIzIwMzA3OzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEg dGl0bGU9bnVyaXQuc3ByZWNoZXJAbnNuLmNvbSBocmVmPSJtYWlsdG86bnVyaXQuc3ByZWNoZXJA bnNuLmNvbSI+U3ByZWNoZXIsIA0KICBOdXJpdCAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKTwvQT4g PC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5Ubzo8 L0I+IDxBIHRpdGxlPXpoYW5nZmF0YWlAaHVhd2VpLmNvbSANCiAgaHJlZj0ibWFpbHRvOnpoYW5n ZmF0YWlAaHVhd2VpLmNvbSI+ZXh0IEZhdGFpIFpoYW5nPC9BPiA8L0RJVj4NCiAgPERJViBzdHls ZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPkNjOjwvQj4gPEEgdGl0bGU9cmFpbmVy LmNsZW1lbnNAbnNuLmNvbSANCiAgaHJlZj0ibWFpbHRvOnJhaW5lci5jbGVtZW5zQG5zbi5jb20i PkNsZW1lbnMsIFJhaW5lciAoTlNOIC0gREUvTXVuaWNoKTwvQT4gOyANCiAgPEEgdGl0bGU9Y2Nh bXBAaWV0Zi5vcmcgaHJlZj0ibWFpbHRvOmNjYW1wQGlldGYub3JnIj5DQ0FNUDwvQT4gOyA8QSAN CiAgdGl0bGU9am9ubmUuc29pbmluZW5AbnNuLmNvbSBocmVmPSJtYWlsdG86am9ubmUuc29pbmlu ZW5AbnNuLmNvbSI+U29pbmluZW4sIA0KICBKb25uZSAoTlNOIC0gRkkvRXNwb28pPC9BPiA7IDxB IHRpdGxlPWRhbmxpQGh1YXdlaS5jb20gDQogIGhyZWY9Im1haWx0bzpkYW5saUBodWF3ZWkuY29t Ij5MaSBEYW48L0E+IDsgPEEgdGl0bGU9aGFuamlhbnJ1aUBodWF3ZWkuY29tIA0KICBocmVmPSJt YWlsdG86aGFuamlhbnJ1aUBodWF3ZWkuY29tIj5oYW4gamlhbnJ1aTwvQT4gOyA8QSANCiAgdGl0 bGU9bGloYW5AY2hpbmFtb2JpbGUuY29tIA0KICBocmVmPSJtYWlsdG86bGloYW5AY2hpbmFtb2Jp bGUuY29tIj5saWhhbkBjaGluYW1vYmlsZS5jb208L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJG T05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IEZyaWRheSwgT2N0b2JlciAy MywgMjAwOSA5OjQwIFBNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYj MjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gUkU6IEktRCANCiAgQWN0aW9uOmRyYWZ0LXpoYW5nLWNj YW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAwLnR4dDwvRElWPg0KICA8RElWPjxCUj48L0RJVj4N CiAgPERJViBjbGFzcz1TZWN0aW9uMT4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SGkgDQogIEZhdGFpLDxvOnA+PC9v OnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Q09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogQXJpYWwiPlRoYW5rcyBmb3IgeW91ciANCiAgcmVz cG9uc2UuPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFs PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJz cDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiBBcmlhbCI+UmVmZXJyaW5nIHRvIGEgDQog IGRvY3VtZW50IHdoaWNoIGlzIG5vdCBhIHN0YW5kYXJkIGlzIHByb2JsZW1hdGljIGFuZCBldmVu IGNvbmZ1c2luZy4gSSBhbSBub3QgDQogIHN1cmUgdGhhdCBhbGwgdGhlIElFVEYgY29sbGVhZ3Vl cyBjb3VsZCByZWFsaXplIHRoYXQgYSBzdXBwbGVtZW50IGRvY3VtZW50IGluIA0KICB0aGUgSVRV LVQgaXMgbm90IGNvbnNpZGVyZWQgYXMgYSBzdGFuZGFyZC4gQXMgeW91IGFncmVlZCBiZWxvdywg PFU+Ry5TdXA0MyBpcyANCiAgTk9UIGEgc3RhbmRhcmQ8L1U+LiA8bzpwPjwvbzpwPjwvU1BBTj48 L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1i bGFjayBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFj azsgRk9OVC1GQU1JTFk6IEFyaWFsIj5JIGJlbGlldmUgaXQgaXMgTk9UIA0KICBpbiB0aGUgc2Nv cGUgb2YgQ0NBTVAgdG8gZGVmaW5lIHRoZSBkYXRhcGxhbmUgYmVoYXZpb3Igb2YgT0RVIHN3aXRj aGluZ4V3ZSBjYW4gDQogIGRlZmluZSBhIGNvbnRyb2wgcGxhbmUgZm9yIGEgc3RhbmRhcmQgZGF0 YXBsYW5lIGFuZCByZWZlciB0byB0aGUgZGF0YXBsYW5lIA0KICBzdGFuZGFyZCBiZWhhdmlvci4g PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiBBcmlhbCI+T25jZSAoYW5kIGlmKSBp dCBpcyANCiAgZGVmaW5lZCBhcyBhIHN0YW5kYXJkIGJlaGF2aW9yIGluIHRoZSBJVFUtVCwgdGhl cmUgd2lsbCBiZSByb29tIHRvIHNwZWNpZnkgYW4gDQogIGV4dGVuc2lvbiBmb3IgR01QTFMgKGlm IG5lY2Vzc2FyeSkgdG8gc3VwcG9ydCBpdC4gDQo8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibGFjayBzaXpl PTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1G QU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6IEFy aWFsIj5BbHNvLCBJIHdvdWxkIGxpa2UgDQogIHRvIG5vdGUgdGhhdCBpdCB3YXMgTkVWRVIgZGlz Y3Vzc2VkIGluIFNHMS9RMTEgdG8gYWxsb3cgb3RoZXIgbWFwcGluZ3MgdGhhbiANCiAgT0RVMmUg aW50byBPRFUzZS4gSXQgd2FzIGV2ZW4gPEI+PEk+PFU+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdF SUdIVDogYm9sZDsgRk9OVC1TVFlMRTogaXRhbGljIj5leHBsaWNpdGx5IA0KICBzdGF0ZWQ8L1NQ QU4+PC9VPjwvST48L0I+IHRoYXQgbm8gb3RoZXIgbWFwcGluZyBzaG91bGQgYmUgZGVzY3JpYmVk IGluIA0KICBHLlN1cDQzLiBUaGUgV1AzIHJlcG9ydCBmcm9tIHRoZSBwbGVuYXJ5IGluIERlY2Vt YmVyIDIwMDggc3RhdGVzIHRoYXQgOiJBZnRlciANCiAgZGlzY3Vzc2lvbiwgdGhlIGFncmVlbWVu dCB3YXMgcmVhY2hlZCB0byBkb2N1bWVudCB0d28gdmVyc2lvbnMgb2YgT0RVM2UsIG9uZSANCiAg YmFzZWQgb24gdGhlIEh1YXdlaSBhbmQgQ01DQyBwcm9wb3NhbCAodXNpbmcgdGhlIGV2ZW50dWFs IEdNUCBjaG9zZW4gZm9yIE9EVTQpIA0KICBhbmQgdGhlIG90aGVyIGJhc2VkIG9uIHRoZSBOVFQg YW5kIDxTVDE6UExBQ0UgdzpzdD0ib24iPjxTVDE6Q09VTlRSWS1SRUdJT04gDQogIHc6c3Q9Im9u Ij5KYXBhbjwvU1QxOkNPVU5UUlktUkVHSU9OPjwvU1QxOlBMQUNFPiBwPC9TUEFOPjwvRk9OVD48 Rk9OVCANCiAgY29sb3I9YmxhY2s+PFNQQU4gbGFuZz1FTi1HQiBzdHlsZT0iQ09MT1I6IGJsYWNr Ij5yb3Bvc2Fscy4mbmJzcDsgQWdyZWVtZW50IA0KICB3YXMgcmVhY2hlZCB0byA8L1NQQU4+PC9G T05UPjxTVFJPTkc+PEI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiANCiAgY29sb3I9Ymxh Y2s+PFNQQU4gbGFuZz1FTi1HQiBzdHlsZT0iQ09MT1I6IGJsYWNrIj5vbmx5IGRvY3VtZW50IHRo ZSBtYXBwaW5nIG9mIA0KICBmb3VyIDEwR0JBU0UtUiBjbGllbnRzPC9TUEFOPjwvRk9OVD48L0I+ PC9TVFJPTkc+PEZPTlQgY29sb3I9YmxhY2s+PFNQQU4gDQogIGxhbmc9RU4tR0Igc3R5bGU9IkNP TE9SOiBibGFjayI+IGludG8gZWFjaCBvZiB0aGVzZSB0d28gdmVyc2lvbnMgb2YgT0RVM2UgaW4g DQogIGFuIHVwZGF0ZWQgRy5TdXA0My4iLjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQog IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPWJs YWNrIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgQ09MT1I6IGJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+TmV2ZXJ0aGVs ZXNzLCBldmVuIGlmIA0KICBzcGVjaWZpZWQgaW4gRy5TdXA0Mywgd2UgbmVlZCB0byBrZWVwIGlu IG1pbmQgdGhhdCB0aGlzIGlzIE5PVCBhIHN0YW5kYXJkIGFuZCANCiAgd2UgY2Fubm90IHJlZmVy IHRvIGl0IGFzIHN1Y2guPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5CZXN0IA0KICByZWdh cmRzLDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5OdXJpdDxvOnA+PC9v OnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFy aWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBD T0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48 L0ZPTlQ+PC9QPg0KICA8RElWPg0KICA8RElWIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iVEVYVC1B TElHTjogY2VudGVyIiBhbGlnbj1jZW50ZXI+PEZPTlQgDQogIGZhY2U9IlRpbWVzIE5ldyBSb21h biIgc2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPg0KICA8SFIgdGFiSW5kZXg9 LTEgYWxpZ249Y2VudGVyIHdpZHRoPSIxMDAlIiBTSVpFPTI+DQogIDwvU1BBTj48L0ZPTlQ+PC9E SVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Qj48Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PFNQ QU4gDQogIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTogVGFob21hIj5Gcm9tOjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICBmYWNlPVRhaG9t YSBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFRhaG9t YSI+IGV4dCANCiAgRmF0YWkgWmhhbmcgW21haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb21dIDxC Uj48Qj48U1BBTiANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TZW50OjwvU1BBTj48L0I+ IEZyaWRheSwgT2N0b2JlciAyMywgMjAwOSA5OjQwIA0KICBBTTxCUj48Qj48U1BBTiBzdHlsZT0i Rk9OVC1XRUlHSFQ6IGJvbGQiPlRvOjwvU1BBTj48L0I+IFNwcmVjaGVyLCBOdXJpdCAoTlNOIC0g DQogIElML0hvZCBIYVNoYXJvbik8QlI+PEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xk Ij5DYzo8L1NQQU4+PC9CPiBDbGVtZW5zLCANCiAgUmFpbmVyIChOU04gLSBERS9NdW5pY2gpOyBD Q0FNUDsgU29pbmluZW4sIEpvbm5lIChOU04gLSBGSS9Fc3Bvbyk7IExpIERhbjsgaGFuIA0KICBq aWFucnVpOyBsaWhhbkBjaGluYW1vYmlsZS5jb208QlI+PEI+PFNQQU4gDQogIHN0eWxlPSJGT05U LVdFSUdIVDogYm9sZCI+U3ViamVjdDo8L1NQQU4+PC9CPiBSZTogSS1EIA0KICBBY3Rpb246ZHJh ZnQtemhhbmctY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDAudHh0PC9TUEFOPjwvRk9OVD48 bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRp bWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8RElWPg0KICA8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJ WkU6IDEycHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SGkgDQogIE51cml0LDwvU1BBTj48L0ZPTlQ+ PG86cD48L286cD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9O VCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPERJ Vj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0z PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogQXJpYWwiPlRo YW5rcyBmb3IgeW91ciANCiAgY29tbWVudHMuPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48 L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJ WkU6IDEycHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+UGxlYXNlIHNlZSBiZWxvdyANCiAgZm9yJm5i c3A7aW4tbGluZSZuYnNwO3Jlc3BvbnNlcy48L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwv RElWPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNs YXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiAN CiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05U PjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRp bWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9O VD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ Jm5ic3A7PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6IFNpbVN1biI+VGhhbmtzPC9TUEFOPjwvRk9O VD48bzpwPjwvbzpwPjwvUD48L0RJVj4NCiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1T SVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8 RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0zPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogU2ltU3VuIj5GYXRhaTxC Uj4mbmJzcDs8QlI+QWR2YW5jZWQgDQogIFRlY2hub2xvZ3kgRGVwYXJ0bWVudDxCUj5XaXJlbGlu ZSBOZXR3b3JraW5nIEJ1c2luZXNzIFVuaXQ8QlI+SHVhd2VpIA0KICBUZWNobm9sb2dpZXMgQ28u LCBMVEQuPEJSPkh1YXdlaSBCYXNlLCBCYW50aWFuLCBMb25nZ2FuZyw8QlI+U2hlbnpoZW4gNTE4 MTI5IA0KICBQLlIuQ2hpbmE8QlI+VGVsOiArODYtNzU1LTI4OTcyOTEyPEJSPkZheDogDQogICs4 Ni03NTUtMjg5NzI5MzU8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICA8QkxP Q0tRVU9URSANCiAgc3R5bGU9IkJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctUklH SFQ6IDBjbTsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IFBBRERJTkctTEVGVDogNHB0OyBQQURE SU5HLUJPVFRPTTogMGNtOyBNQVJHSU46IDVwdCAwY20gNXB0IDMuNzVwdDsgQk9SREVSLUxFRlQ6 IGJsYWNrIDEuNXB0IHNvbGlkOyBQQURESU5HLVRPUDogMGNtOyBCT1JERVItQk9UVE9NOiBtZWRp dW0gbm9uZSI+DQogICAgPERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1T aW1TdW4gc2l6ZT0xPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgRk9OVC1GQU1J TFk6IFNpbVN1biI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgICA8bzpwPjwvbzpw PjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgIDxESVYgc3R5bGU9ImZvbnQtY29sb3I6IGJs YWNrIj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQi PjxCPjxGT05UIGZhY2U9U2ltU3VuIA0KICAgIHNpemU9MT48U1BBTiANCiAgICBzdHlsZT0iRk9O VC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogOXB0OyBGT05ULUZBTUlMWTogU2ltU3VuIj5Gcm9t OjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICAgIGZhY2U9U2ltU3VuIHNpemU9MT48U1BBTiBz dHlsZT0iRk9OVC1TSVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiBTaW1TdW4iPiA8QSANCiAgICB0aXRs ZT1udXJpdC5zcHJlY2hlckBuc24uY29tIGhyZWY9Im1haWx0bzpudXJpdC5zcHJlY2hlckBuc24u Y29tIj5TcHJlY2hlciwgDQogICAgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbik8L0E+IDxv OnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgPERJVj4NCiAgICA8UCBjbGFz cz1Nc29Ob3JtYWw+PEI+PEZPTlQgZmFjZT1TaW1TdW4gc2l6ZT0xPjxTUEFOIA0KICAgIHN0eWxl PSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiBTaW1TdW4i PlRvOjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICAgIGZhY2U9U2ltU3VuIHNpemU9MT48U1BB TiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiBTaW1TdW4iPiA8QSANCiAgICB0 aXRsZT16aGFuZ2ZhdGFpQGh1YXdlaS5jb20gDQogICAgaHJlZj0ibWFpbHRvOnpoYW5nZmF0YWlA aHVhd2VpLmNvbSI+emhhbmdmYXRhaUBodWF3ZWkuY29tPC9BPiA7IDxBIA0KICAgIHRpdGxlPWRh bmxpQGh1YXdlaS5jb20gaHJlZj0ibWFpbHRvOmRhbmxpQGh1YXdlaS5jb20iPmRhbmxpQGh1YXdl aS5jb208L0E+IDsgDQogICAgPEEgdGl0bGU9aGFuamlhbnJ1aUBodWF3ZWkuY29tIA0KICAgIGhy ZWY9Im1haWx0bzpoYW5qaWFucnVpQGh1YXdlaS5jb20iPmhhbmppYW5ydWlAaHVhd2VpLmNvbTwv QT4gOyA8QSANCiAgICB0aXRsZT1saWhhbkBjaGluYW1vYmlsZS5jb20gDQogICAgaHJlZj0ibWFp bHRvOmxpaGFuQGNoaW5hbW9iaWxlLmNvbSI+bGloYW5AY2hpbmFtb2JpbGUuY29tPC9BPiANCiAg ICA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgIDxESVY+DQogICAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxCPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9MT48U1BBTiANCiAgICBz dHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogOXB0OyBGT05ULUZBTUlMWTogU2lt U3VuIj5DYzo8L1NQQU4+PC9GT05UPjwvQj48Rk9OVCANCiAgICBmYWNlPVNpbVN1biBzaXplPTE+ PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogOXB0OyBGT05ULUZBTUlMWTogU2ltU3VuIj4gPEEgDQog ICAgdGl0bGU9cmFpbmVyLmNsZW1lbnNAbnNuLmNvbSBocmVmPSJtYWlsdG86cmFpbmVyLmNsZW1l bnNAbnNuLmNvbSI+Q2xlbWVucywgDQogICAgUmFpbmVyIChOU04gLSBERS9NdW5pY2gpPC9BPiA7 IDxBIHRpdGxlPWNjYW1wQGlldGYub3JnIA0KICAgIGhyZWY9Im1haWx0bzpjY2FtcEBpZXRmLm9y ZyI+Y2NhbXBAaWV0Zi5vcmc8L0E+IDsgPEEgDQogICAgdGl0bGU9am9ubmUuc29pbmluZW5AbnNu LmNvbSBocmVmPSJtYWlsdG86am9ubmUuc29pbmluZW5AbnNuLmNvbSI+U29pbmluZW4sIA0KICAg IEpvbm5lIChOU04gLSBGSS9Fc3Bvbyk8L0E+IDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+ PC9ESVY+DQogICAgPERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PEZPTlQgZmFjZT1T aW1TdW4gc2l6ZT0xPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1T SVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiBTaW1TdW4iPlNlbnQ6PC9TUEFOPjwvRk9OVD48L0I+PEZP TlQgDQogICAgZmFjZT1TaW1TdW4gc2l6ZT0xPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsg Rk9OVC1GQU1JTFk6IFNpbVN1biI+IA0KICAgIFRodXJzZGF5LCBPY3RvYmVyIDIyLCAyMDA5IDE6 NDIgQU08bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgIDxESVY+DQogICAg PFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxGT05UIGZhY2U9U2ltU3VuIHNpemU9MT48U1BBTiANCiAg ICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogOXB0OyBGT05ULUZBTUlMWTog U2ltU3VuIj5TdWJqZWN0OjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICAgIGZhY2U9U2ltU3Vu IHNpemU9MT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiBTaW1TdW4i PiBSRTogDQogICAgSS1EIA0KICAgIEFjdGlvbjpkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1nNzA5 LWZyYW1ld29yay0wMC50eHQ8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAg IDxESVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21h biIgc2l6ZT0zPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQt U0laRTogMTBwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBj bGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiAN CiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5EZWFyIGF1dGhvcnMsIDxvOnA+PC9vOnA+PC9T UEFOPjwvRk9OVD48L1A+DQogICAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+PG86 cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29QbGFpblRl eHQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0Ij5UaGFua3MgZm9yIHN1Ym1pdHRpbmcgeW91ciBkb2N1bWVudCBvbiAiRnJh bWV3b3JrIA0KICAgIGZvciBHTVBMUyBhbmQgUENFIENvbnRyb2wgb2YgRy43MDkgT3B0aWNhbCBU cmFuc3BvcnQgDQogICAgTmV0d29ya3MiLjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQog ICAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+ PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+PG86cD4mbmJzcDs8L286cD48L1NQ QU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFjZT0iQ291 cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5XZSBo YXZlIHJldmlld2VkIHRoZSBkb2N1bWVudCBhbmQgd2UgYXJlIGEgbGl0dGxlIA0KICAgIGJpdCBj b25jZXJuZWQgdG8gZmluZCBvdXQgdGhhdCBzb21lIHNpZ25pZmljYW50IGl0ZW1zIGRlc2NyaWJl ZCBpbiB0aGUgDQogICAgZG9jdW1lbnQgYXJlIG5vdCBhbGlnbmVkIHdpdGggd2hhdCBpcyBkZWZp bmVkIGluIA0KICAgIEcuNzA5LjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgPFAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4g DQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9G T05UPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iQ291cmllciBOZXci IHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog J0NvdXJpZXIgTmV3JyI+RXNwZWNpYWxseSB0aGUgbWFwcGluZ3MgDQogICAgaW50byBPRFUzZTEg YW5kIE9EVTNlMiBhcmUgb25seSBkZWZpbmVkIGluIEcuU3VwNDMgd2hpY2ggaXMgbm90IGEgc3Rh bmRhcmQuIA0KICAgIDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPkluIGFkZGl0 aW9uIEcuU3VwNDMgZG9lcyANCiAgICBub3QgZGVmaW5lIG1hcHBpbmdzIG9mIE9EVTAsIE9EVTEs IE9EVTIgYW5kJm5ic3A7T0RVZmxleCBpbnRvIE9EVTNlMi4gVGhlIA0KICAgIG9ubHkgbWFwcGlu Z3MgdGhhdCBhcmUgZGVmaW5lZCBpbiBHLlN1cDQzIGFyZSA0eCANCiAgICBPRFUyZS48L1NQQU4+ PC9GT05UPjxvOnA+PC9vOnA+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAx MnB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICAgIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPltG YXRhaV0gWWVzLCB5b3UgDQogICAgYXJlIHJpZ2h0IGFuZCB3ZSBhbHNvIGluZGljYXRlZCBpbiB0 aGlzIGRyYWZ0IHRoYXQgT0RVM2UxIGFuZCBPRFUzZTIgYXJlIA0KICAgIGRlZmluZWQgaW4gPEEg bmFtZT1PTEVfTElOSzI+PC9BPjxBIG5hbWU9T0xFX0xJTksxPkcuU3VwNDM8L0E+LiBZb3Uga25v dyANCiAgICBHLlN1cCBpcyBub3Qgc3RhbmRhcmQgY3VycmVudGx5LHNvIEkgdGhpbmsgd2UgaGF2 ZSBzb21lIG9wdGlvbnMgZm9yIHRoaXMuIA0KICAgICgxKWFkZCBhIG5vdGUgdG8gZXhwbGFpbiB0 aGF0IE9EVTNlMSBhbmQgT0RVM2UyIGFyZSBzdGlsbCBub24tc3RhbmRhcmQgDQogICAgZXhwbGlj aXRseSAoMikgY2hhbmdlIHRoZSB0aXRsZSBvZiB0aGlzIGRyYWZ0IHRvICJGcmFtZXdvcmsgZm9y IEdNUExTIGFuZCANCiAgICBQQ0UgQ29udHJvbCBvZiBPcHRpY2FsIFRyYW5zcG9ydCBOZXR3b3Jr cyImbmJzcDsoMykgbW92ZSBPRFUzZTImbmJzcDsgdG8gYW4gDQogICAgYXBwZW5kaXguJm5ic3A7 IDwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SW4gYWRkaXRpb24s IEkgDQogICAgdGhpbmsgd2UgY2FuIGNvdmVyIE9EVTNlMSBhbmQgT0RVM2UyIGluIHRoaXMgZHJh ZnQgYXQgdGhpcyBzdGFnZSAoaS5lLiwgDQogICAgaW5kaXZpZHVhbCBkcmFmdCksIGJlY2F1c2Ug dGhleSBhcmUgYmVpbmcgZGV2ZWxvcGVkIGluIElUVS1UIGFuZCBtYXkgYmUgDQogICAgYWNjZXB0 ZWQgYnkgSVRVLVQgc29tZSBkYXkuPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD4NCiAgICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BB TiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6 IEFyaWFsIj5JIHdpbGwgcmVmbGVjdCB0aGlzIA0KICAgIGluIHRoZSBuZXh0IHZlcnNpb24uIDwv U1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyciPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFO PjwvRk9OVD48L1A+DQogICAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+PG86cD4m bmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0Ij5XZSBhcmUgYWZyYWlkIHRoYXQgdGhpcyBpcyBub3QgaW5saW5lIHdpdGggdGhl IHZpZXcgDQogICAgb2YgdGhlIG1ham9yaXR5IG9mIHBhcnRpY2lwYW50cyBpbiBTRzE1L1ExMS48 bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgPFAgY2xh c3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4g DQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBB cmlhbCI+W0ZhdGFpXSBJIGRvbid0IA0KICAgIGtub3cgd2hldGhlciBpdCBpcyB0cnVlIG9yIG5v dC4gQnV0IEkgdGhpbmsgd2UgY2FuIGhlYXIgdGhlIG9waW5pb25zIGZyb20gDQogICAgU0cxNS9R MTEuPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29QbGFpblRl eHQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQ IGNsYXNzPU1zb1BsYWluVGV4dD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFO IA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPkV4Y2VwdCBvZiB0aGUgZXh0ZW5zaW9ucyB0 aGF0IGFyZSBhbHJlYWR5IGRlc2NyaWJlZCANCiAgICBpbiB0d28gZHJhZnQgKGRyYWZ0LWNlY2Nh cmVsbGlmdXhoLWNjYW1wLWdtcGxzLWV4dC1mb3ItZXZvbC1vdG4sIA0KICAgIGRyYWZ0LXpoYW5n LWNjYW1wLWdtcGxzLWV2b2x2aW5nLWc3MDkpLCBhbGwgb3RoZXIgY29udGVudCBvZiBzZWN0aW9u IDMsIDQgaXMgDQogICAgY29waWVkIGZyb20gSVRVIHN0YW5kYXJkcy4gV291bGQgbm90IGl0IGJl IGJldHRlciB0byBqdXN0IHJlZmVyIHRvIHRoZSBJVFUtVCANCiAgICBkb2N1bWVudD88bzpwPjwv bzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48Rk9OVCBm YWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgPFAgY2xhc3M9TXNv UGxhaW5UZXh0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+ W0ZhdGFpXSBJbiBTZWN0aW9uIA0KICAgIDMsIHNvbWUgcGFydCBvZiBpbmZvcm1hdGlvbiBpcyBm cm9tIEcuNzA5IGFuZCBHLjg3MiZuYnNwO2FuZCB3ZSByZWZlcmVuY2UgDQogICAgdGhpcyByZWNv bW1lbmRhdGlvbnMgZXhwbGljaXRseS4gV2UganVzdCB0cnkgdG8gZ2l2ZSBhIGJyaWVmIG92ZXJ2 aWV3IG9mIE9UTiANCiAgICB0byBDQ0FNUCBleHBlcnRzIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9m IENvbnRyb2wgUGxhbmUgYW5kIG1ha2UgZXZlcnlvbmUgDQogICAgcXVpY2tseSB1bmRlcnN0YW5k IHdoeSB3ZSBuZWVkIG1vcmUgY29uc2lkZXJhdGlvbnMgb24gT1ROIGNvbnRyb2wuIEkgdGhpbmsg DQogICAgaXQgaXMgcmVhbGx5IHRvdWdoIGZvciBldmVyeW9uZSB0byBnbyB0aHJvdWdoIEcuNzA5 LCBHLjg3MiBhbmQgb3RoZXIgDQogICAgcmVjb21tZW5kYXRpb25zIGRldGFpbGVkbHkuJm5ic3A7 QXMgZm9yICZuYnNwO1NlY3Rpb24gNCwgSSBkb24ndCBrbm93IHdoeSANCiAgICB5b3Ugc2FpZCB0 aGF0IGl0IGlzIGNvcGllZCBmcm9tIElUVSBzdGFuZGFyZHMuJm5ic3A7IEluIFNlY3Rpb24gNCwg DQogICAgaXQmbmJzcDtkZXNjcmliZXMgdGhlIGNvbm5lY3Rpb24gbWFuYWdlbWVudCZuYnNwO21v ZGVsIGZvciBPVE4gDQogICAgbmV0d29ya3MsJm5ic3A7d2hpY2ggaXMgYmFzZWQgb24gb3VyIHVu ZGVyc3RhbmRpbmcgYW5kIHNvbWUgZGlzY3Vzc2lvbnMgaW4gDQogICAgSVRVLVQgUTEyLiZuYnNw OzwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+DQogICAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQt U0laRTogMTBwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBj bGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiAN CiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L1NQ QU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFjZT0iQ291 cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij5OdXJp dDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8 L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv U1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFs IGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwv Rk9OVD48L1A+DQogICAgPEJMT0NLUVVPVEUgDQogICAgc3R5bGU9IkJPUkRFUi1SSUdIVDogbWVk aXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBjbTsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IFBB RERJTkctTEVGVDogNHB0OyBQQURESU5HLUJPVFRPTTogMGNtOyBNQVJHSU46IDVwdCAwY20gNXB0 IDMuNzVwdDsgQk9SREVSLUxFRlQ6IGJsdWUgMS41cHQgc29saWQ7IFBBRERJTkctVE9QOiAwY207 IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lIj4NCiAgICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4 dD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZP TlQtU0laRTogMTBwdCI+Jmd0OyA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAg PFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQ QU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IC0tLS0tT3JpZ2luYWwgDQog ICAgICBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPFAg Y2xhc3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4g DQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IEZyb206IGktZC1hbm5vdW5jZS1i b3VuY2VzQGlldGYub3JnIA0KICAgICAgPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAg ICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0y PjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jmd0OyBbbWFpbHRvOmktZC1h bm5vdW5jZS1ib3VuY2VzQGlldGYub3JnXSBPbiANCiAgICAgIEJlaGFsZiBPZiBleHQgPG86cD48 L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0la RTogMTBwdCI+Jmd0OyANCiAgICAgIEludGVybmV0LURyYWZ0c0BpZXRmLm9yZzxvOnA+PC9vOnA+ PC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFj ZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQiPiZndDsgU2VudDogRnJpZGF5LCBPY3RvYmVyIDE2LCAyMDA5IDExOjQ1IA0KICAgICAgQU08 bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0Ij4mZ3Q7IFRvOiANCiAgICAgIGktZC1hbm5vdW5jZUBpZXRmLm9yZzxvOnA+ PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZP TlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQiPiZndDsgU3ViamVjdDogSS1EIA0KICAgICAgQWN0aW9uOmRyYWZ0LXpoYW5nLWNj YW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAwLnR4dCANCiAgICAgIDxvOnA+PC9vOnA+PC9TUEFO PjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFjZT0iQ291 cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZn dDsgPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb1BsYWlu VGV4dD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdCI+Jmd0OyBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgDQogICAgICBvbi1saW5lIDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQog ICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9 Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZndDsgSW50ZXJuZXQtRHJh ZnRzIA0KICAgICAgZGlyZWN0b3JpZXMuPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAg ICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0y PjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jmd0OyA8bzpwPjwvbzpwPjwv U1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 Ij4mZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgIFRpdGxlJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogDQogICAgICBGcmFt ZXdvcmsgZm9yIEdNUExTIGFuZCBQQ0UgQ29udHJvbCA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+ PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 IiBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IG9mIEcu NzA5IE9wdGljYWwgVHJhbnNwb3J0IA0KICAgICAgTmV0d29ya3M8bzpwPjwvbzpwPjwvU1BBTj48 L0ZPTlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7 ICZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgIEF1dGhvcihzKSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA6IEYuIFpoYW5nLCBldCANCiAgICAgIGFsLjxvOnA+PC9vOnA+PC9T UEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFjZT0i Q291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQi PiZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgICAgRmlsZW5hbWUmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiANCiAgICAgIGRyYWZ0LXpoYW5nLWNjYW1wLWdt cGxzLWc3MDktZnJhbWV3b3JrLTAwLnR4dDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQog ICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9 Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZndDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7IA0KICAgICAgUGFnZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiANCiAgICAgIDI3PG86cD48L286cD48L1NQQU4+PC9G T05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48Rk9OVCBmYWNlPSJDb3VyaWVy IE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jmd0OyAm bmJzcDsmbmJzcDsmbmJzcDsgDQogICAgICBEYXRlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogDQogICAgICAyMDA5LTEw LTE2PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb1BsYWlu VGV4dD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdCI+Jmd0OyA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAg ICAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+ PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IFRoaXMgZG9jdW1lbnQg cHJvdmlkZXMgYSBmcmFtZXdvcmsgZm9yIA0KICAgICAgYXBwbHlpbmcgR2VuZXJhbGl6ZWQgTXVs aXQtPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb1BsYWlu VGV4dD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdCI+Jmd0OyBQcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKEdNUExTKSBh bmQgdGhlIFBhdGggDQogICAgICBDb21wdXRhdGlvbiBFbGVtZW50IDxvOnA+PC9vOnA+PC9TUEFO PjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFjZT0iQ291 cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZn dDsgKFBDRSkgYXJjaGl0ZWN0dXJlIHRvIHRoZSBjb250cm9sIG9mIEcuNzA5IA0KICAgICAgT3B0 aWNhbCBUcmFuc3BvcnQgTmV0d29ya3MgPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAg ICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0y PjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jmd0OyAoT1ROKSBhcyBzcGVj aWZpZWQgaW4gdGhlIElUVS1UIEcuNzA5IA0KICAgICAgcmVjb21tZW5kYXRpb24sIGluY2x1ZGlu ZyB0aGUgPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb1Bs YWluVGV4dD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5 bGU9IkZPTlQtU0laRTogMTBwdCI+Jmd0OyBlbmhhbmNlZCBmdW5jdGlvbmFsaXR5IGluIHRoZSBy ZWNlbnRseSANCiAgICAgIGNvbnNlbnRlZCByZXZpc2lvbi4gPG86cD48L286cD48L1NQQU4+PC9G T05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48Rk9OVCBmYWNlPSJDb3VyaWVy IE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jmd0OyA8 bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0 PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0Ij4mZ3Q7Jm5ic3A7IDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQog ICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9 Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZndDsmbmJzcDsgPG86cD48 L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0la RTogMTBwdCI+Jmd0OyZuYnNwOyA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAg PFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQ QU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IHpoYW5nPG86cD48L286cD48 L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBw dCI+Jmd0OyA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNv UGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+ DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNp emU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZndDsgPG86cD48L286 cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48Rk9OVCBm YWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTog MTBwdCI+Jmd0OyA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9 TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAg ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48 L1A+DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXci IHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZndDsmbmJzcDsm bmJzcDsgRXhwaXJlcyBBcHJpbCANCiAgICAgIDIwMTA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+ PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 IiBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IDxvOnA+ PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZP TlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQiPiZndDsgPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNs YXNzPU1zb1BsYWluVGV4dD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0K ICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jmd0OyA8bzpwPjwvbzpwPjwvU1BBTj48L0ZP TlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3IiBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IDxv OnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQiPiZndDsgPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQ IGNsYXNzPU1zb1BsYWluVGV4dD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFO IA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jmd0OyZuYnNwOyZuYnNwOyBbcGFnZSAx XSANCiAgICAgIDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1N c29QbGFpblRleHQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICAg IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZndDsgPG86cD48L286cD48L1NQQU4+PC9GT05UPjwv UD4NCiAgICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIg c2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jmd0OyANCiAgICAg IGRyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAwLnR4dDxvOnA+PC9vOnA+ PC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFj ZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQiPiZndDsgPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1z b1BsYWluVGV4dD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgICAg c3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jmd0OyA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9Q Pg0KICAgICAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBz aXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IDxvOnA+PC9v OnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQg ZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQiPiZndDsmbmJzcDsmbmJzcDsgT2N0b2JlciAyMDA5IA0KICAgICAgPG86cD48L286cD48 L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48Rk9OVCBmYWNl PSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBw dCI+Jmd0OyZuYnNwOyA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPFAgY2xh c3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQog ICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9O VD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFjZT0iQ291cmllciBO ZXciIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZndDsgQ29u dmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50IA0KICAgICAgPG86cD48L286cD48L1NQQU4+ PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jmd0 OyA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvUGxhaW5U ZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAi UkVRVUlSRUQiLCANCiAgICAgICJTSEFMTCIsICJTSEFMTCBOT1QiLCA8bzpwPjwvbzpwPjwvU1BB Tj48L0ZPTlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4m Z3Q7ICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCANCiAgICAg IGFuZCAiT1BUSU9OQUwiIGluIHRoaXMgPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAg ICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0y PjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jmd0OyBkb2N1bWVudCBhcmUg dG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIA0KICAgICAgaW4gW1JGQzIxMTldLjxvOnA+ PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZP TlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQiPiZndDsgPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNs YXNzPU1zb1BsYWluVGV4dD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0K ICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Jmd0OyBBIFVSTCBmb3IgdGhpcyBJbnRlcm5l dC1EcmFmdCANCiAgICAgIGlzOjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8 UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BB TiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZndDsgDQogICAgICBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC16aGFuZy1jY2FtcC1nbXBscy1nNzxvOnA+ PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZP TlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQiPiZndDsgDQogICAgICAwOS1mcmFtZXdvcmstMDAudHh0PG86cD48L286cD48L1NQ QU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4dD48Rk9OVCBmYWNlPSJD b3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+ Jmd0OyA8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvUGxh aW5UZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogICAgICBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFi bGUgYnkgDQogICAgICBhbm9ueW1vdXMgRlRQIGF0OjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48 L1A+DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXci IHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZndDsgDQogICAg ICBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzxvOnA+PC9vOnA+PC9TUEFOPjwv Rk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQgZmFjZT0iQ291cmll ciBOZXciIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPiZndDsg PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb1BsYWluVGV4 dD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZP TlQtU0laRTogMTBwdCI+Jmd0OyBCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBh IE1JTUUgDQogICAgICBjb21wbGlhbnQgbWFpbCByZWFkZXI8bzpwPjwvbzpwPjwvU1BBTj48L0ZP TlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3IiBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IGlt cGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIA0KICAgICAgQVNDSUkg dmVyc2lvbiBvZiB0aGU8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPFAgY2xh c3M9TXNvUGxhaW5UZXh0PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQog ICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0Ij4mZ3Q7IEludGVybmV0LURyYWZ0LjxvOnA+PC9v OnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29QbGFpblRleHQ+PEZPTlQg ZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQiPiZndDsgDQogIDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9CTE9DS1FVT1RF PjwvQkxPQ0tRVU9URT48L0RJVj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_aw1xSv/K8/GstHSrCzHRvA)-- From daniele.ceccarelli@ericsson.com Mon Oct 26 07:03:51 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E01B28C0EA for ; Mon, 26 Oct 2009 07:03:51 -0700 (PDT) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWBggUxVkzUi for ; Mon, 26 Oct 2009 07:03:45 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C047D28C242 for ; Mon, 26 Oct 2009 07:03:44 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-19-4ae5ac4c5237 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 4A.45.31706.C4CA5EA4; Mon, 26 Oct 2009 15:03:56 +0100 (CET) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 15:03:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5645.27A0A6DA" Date: Mon, 26 Oct 2009 15:03:54 +0100 Message-ID: In-Reply-To: <93BC09B2B8795C49B4E3453CE6A45A18A1B27CF2A1@ILPTMAIL02.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] OTN control drafts: draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt Thread-Index: AcpTw6uvQCrAI6zCR6+M0sDh1YX2OgBjPeygADyMXgA= References: <05e001ca53c3$a02e2fb0$704c460a@china.huawei.com> <93BC09B2B8795C49B4E3453CE6A45A18A1B27CF2A1@ILPTMAIL02.ecitele.com> From: "Daniele Ceccarelli" To: "Yechiel Rosengarten" X-OriginalArrivalTime: 26 Oct 2009 14:03:56.0229 (UTC) FILETIME=[284C1F50:01CA5645] X-Brightmail-Tracker: AAAAAA== Cc: CCAMP Subject: Re: [CCAMP] OTN control drafts: draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 14:03:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5645.27A0A6DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yechiel, =20 thank you very much for your suggestion, it is worth distinguishing between GCC1 and GCC2. We'll introduce the modification in the next version of the ID. =20 Best regards Daniele ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Yechiel Rosengarten Sent: domenica 25 ottobre 2009 10.05 To: Fatai Zhang; CCAMP Subject: Re: [CCAMP] OTN control drafts: draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt Hi, =20 >From Paragraph 3.2 of the draft: " 3.2. Verify Transport Mechanism =20 . . . . . =20 Capability of transmitting Test messages using ODUk Trail Trace Identifier (TTI) overhead with frame length of 64 bytes. See ITU G.709 Section 15.2 and Section 15.8 for the structure and definition. The Test message is sent according to [RFC4204 ]. =20 - 0x04 GCC0: Test Message over the GCC0 =20 Capability of transmitting Test messages using the OTUk Overhead General Communications Channel (GCC0). See ITU G.709 Section 15.7 =20 for the structure and definition. The Test message is sent according to [RFC4204 ] using bit-oriented HDLC framing format [RFC1662 ]. =20 - 0x08 GCC1/2: Test Message over the GCC1/2 =20 Capability of transmitting Test messages using the ODUk Overhead General Communications Channels (GCC1/2). See ITU G.709 Section 15.8 for the structure and definition. The Test message is sent according to [RFC4204 ] using bit-oriented HDLC framing format [RFC1662 ]. " =20 In the draft there is no distinguishing between transmitting the test message over GCC1 or GCC2 while the other endpoint of the link may be capable of terminating one of them but not both. Thus I would suggest to allocate separate bit for each.=20 =20 Best Regards, =20 Yechiel Rosengarten System Engineering ECI Telecom Ltd 30 Hasivim St. Petach Tikva 49517 Israel e-mail: yechiel.rosengarten@ecitele.com =20 =20 =20 From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Fatai Zhang Sent: Friday, October 23, 2009 11:32 AM To: CCAMP Subject: [CCAMP] OTN control drafts =20 Hi CCAMPers, =20 You know that there are lots of interests from both a technical and organizational standpoint (e.g., ITU-T SG15/Q12,Q14, IETF CCAMP) on OTN control, since draft-zhang-ccamp-gmpls-evolving-g709-00.txt was presented in IETF 75th meeting. =20 You also know that [G.709 V3] including ODU0, ODU4, ODUflex... was consented by ITU-T SG15 in this October. Therefore, in order to control and manage the OTN networks efficiently, OTN control is really important for the industry. =20 Up to now, we have five drafts about OTN control: (1) draft-zhang-ccamp-gmpls-g709-framework-00.txt =20 (2) draft-zhang-ccamp-gmpls-evolving-g709-03.txt =20 (3) draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt =20 (4) draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt =20 (5) draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt =20 =20 To promote better understanding or the discussions in Hiroshima meeting, we'd appreciate your review and comments. =20 =20 Thanks =20 Authors of these drafts =20 =20 ------_=_NextPart_001_01CA5645.27A0A6DA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Yechiel,
 
thank you very much for your suggestion, it is = worth=20 distinguishing between GCC1 and GCC2.
We'll introduce the modification in the = next version=20 of the ID.
 
Best regards
Daniele

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of Yechiel=20 Rosengarten
Sent: domenica 25 ottobre 2009 10.05
To: = Fatai=20 Zhang; CCAMP
Subject: Re: [CCAMP] OTN control drafts:=20 draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt

Hi,

 

From = Paragraph=20 3.2 of the draft:

“

3.2. =20 Verify Transport Mechanism

 

    =20  . . . . .     

     =20 Capability of transmitting Test messages using ODUk Trail=20 Trace

     =20 Identifier (TTI) overhead with frame length of 64 bytes.  See=20 ITU

     =20 G.709 Section=20 15.2 and Section=20 15.8 for the structure and

     =20 definition.  The Test message is sent according to [RFC4204].

 

     =20 - 0x04 GCC0: Test Message over the GCC0

 

     =20 Capability of transmitting Test messages using the OTUk=20 Overhead

     =20 General Communications Channel (GCC0).  See ITU G.709 Section=20 15.7

     =20 for the structure and definition.  The Test message is=20 sent

     =20 according to [RFC4204] using = bit-oriented HDLC=20 framing format

     =20 [RFC1662].

 

     =20 - 0x08 GCC1/2: Test Message over the GCC1/2

 

     =20 Capability of transmitting Test messages using the ODUk=20 Overhead

     =20 General Communications Channels (GCC1/2).  See ITU G.709=20 Section

     =20 15.8 for the structure and definition.  The Test message is=20 sent

     =20 according to [RFC4204] using = bit-oriented HDLC=20 framing format

     =20 [RFC1662].

“

 

In the = draft=20 there is no distinguishing between transmitting the test message over = GCC1 or=20 GCC2 while the other endpoint of the link may be capable of terminating = one of=20 them but not both. Thus I would suggest to allocate separate bit for = each.=20

 

Best=20 Regards,

 

    =20 Yechiel Rosengarten
     System=20 Engineering
     ECI Telecom=20 Ltd
     30 Hasivim St. Petach Tikva 49517=20 Israel

     e-mail: yechiel.rosengarten@ecitele.com

 

 

From:=20 ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of = Fatai=20 Zhang
Sent: Friday, October 23, 2009 11:32 AM
To:=20 CCAMP
Subject: [CCAMP] OTN control=20 drafts

 

Hi=20 CCAMPers,

 

You know that there are = lots of=20 interests from both a technical and organizational standpoint (e.g., = ITU-T=20 SG15/Q12,Q14, IETF CCAMP) on OTN control, since=20 draft-zhang-ccamp-gmpls-evolving-g709-00.txt was presented in IETF 75th=20 meeting.

 

You also know that = [G.709 V3]=20 including ODU0, ODU4, ODUflex... was consented by ITU-T SG15 in this=20 October.  Therefore, in order to control and manage the OTN = networks=20 efficiently, OTN control is really important for the=20 industry.

 

Up to now, we have five = drafts=20 about OTN control:

(1) draft-zhang-ccamp-gmpls-g709-framework-00.txt=20

(2) draft-zhang-ccamp-gmpls-evolving-g709-03.txt=20

(3) draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt=20

(4) draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt=20

(5) draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt=20

 

To promote better = understanding=20 or the discussions in Hiroshima meeting, we'd appreciate your review and = comments.

 

 

Thanks

 

Authors of these=20 drafts

 

 

------_=_NextPart_001_01CA5645.27A0A6DA-- From root@core3.amsl.com Mon Oct 26 08:15:02 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2C34C3A6905; Mon, 26 Oct 2009 08:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026151502.2C34C3A6905@core3.amsl.com> Date: Mon, 26 Oct 2009 08:15:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rsvp-te-eth-oam-ext-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS RSVP-TE Extensions for Ethernet OAM Configuration Author(s) : A. Takacs, et al. Filename : draft-ietf-ccamp-rsvp-te-eth-oam-ext-02.txt Pages : 19 Date : 2009-10-26 The GMPLS controlled Ethernet Label Switching (GELS) work is extending GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM flow to check connectivity in Ethernet networks. CFM can be also used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This document specifies extensions of GMPLS RSVP-TE to support the setup of the associated Ethernet OAM (CFM and Y.1731) entities adding a technology specific TLV to [OAM-CONF-FWK].Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-eth-oam-ext-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-te-eth-oam-ext-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26081457.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 26 08:30:06 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 39C983A6AAD; Mon, 26 Oct 2009 08:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026153004.39C983A6AAD@core3.amsl.com> Date: Mon, 26 Oct 2009 08:30:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-oam-configuration-fwk-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 15:30:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : OAM Configuration Framework and Requirements for GMPLS RSVP-TE Author(s) : A. Takacs, et al. Filename : draft-ietf-ccamp-oam-configuration-fwk-02.txt Pages : 24 Date : 2009-10-26 OAM is an integral part of transport connections, hence it is required that OAM functions are activated/deactivated in sync with connection commissioning/decommissioning; avoiding spurious alarms and ensuring consistent operation. In certain technologies OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to RSVP-TE to support the establishment and configuration of OAM entities along with LSP signaling.Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-oam-configuration-fwk-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-oam-configuration-fwk-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26081932.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 26 09:45:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A0F4D3A6921; Mon, 26 Oct 2009 09:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091026164501.A0F4D3A6921@core3.amsl.com> Date: Mon, 26 Oct 2009 09:45:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D ACTION:draft-ietf-ccamp-gmpls-ted-mib-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 16:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS Author(s) : M. Miyazawa, T. Otani, K. Kumaki, T. Nadeau Filename : draft-ietf-ccamp-gmpls-ted-mib-06.txt Pages : 27 Date : 2009-10-26 This memo defines the Management Information Base (MIB) objects in order to manage traffic engineering database (TED) information with extension in support of Multi-Protocol Label Switching (MPLS) with traffic engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ted-mib-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ted-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26093915.I-D@ietf.org> --NextPart-- From Attila.Takacs@ericsson.com Mon Oct 26 12:17:49 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178E128C10E for ; Mon, 26 Oct 2009 12:17:49 -0700 (PDT) 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=[AWL=-0.000, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1ElhEd-cLAH for ; Mon, 26 Oct 2009 12:17:44 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 5088C3A68B1 for ; Mon, 26 Oct 2009 12:17:43 -0700 (PDT) X-AuditID: c1b4fb24-b7b12ae000007bda-ed-4ae5f5e37009 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id B7.74.31706.3E5F5EA4; Mon, 26 Oct 2009 20:17:55 +0100 (CET) Received: from esealmw116.eemea.ericsson.se ([153.88.200.7]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 20:17:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5671.0506AE2B" Date: Mon, 26 Oct 2009 20:17:54 +0100 Message-ID: <53CCFDD6E346CB43994852666C210E9108BF9B77@esealmw116.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt- regardingISID error handling Thread-Index: AcpSqVK+wd2bKaYBS7qAjTlddLDxQgDwbG/A References: From: "Attila Takacs" To: X-OriginalArrivalTime: 26 Oct 2009 19:17:55.0341 (UTC) FILETIME=[05487BD0:01CA5671] X-Brightmail-Tracker: AAAAAA== Cc: ccamp@ietf.org Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt- regardingISID error handling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 19:17:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5671.0506AE2B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Choudarypally, Please see inline. Thanks and best regards, Attila ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of choudarypally.subramanyam@wipro.com Sent: Thursday, October 22, 2009 1:51 AM To: ccamp@ietf.org Subject: [CCAMP] draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt- regardingISID error handling =09 =09 Hi , I am currently working on draft "draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt" and I write this email to seek some help from experts. I have two questions regarding the Section 3 paragraph 6. 1) It say "An IB-BEB receiving a PATH message specifying one of its CNPs can locally determine which CBPs have internal connectivity to the I-component supporting the given CNP." How does the CSPF function select egress CNP, based on what criteria? =20 =20 The CNP is the port to which clients of the PBB-TE domain are connected to. CSPF should consider which clients the Eth-LSP is meant to support. 2) Further it says "On the other hand, if there is information on the service (I-SID) that the given ESP will support, then the IB-BEB MUST first determine which PIP and CBP is configured with the I-SID and MUST assign that CBP to the ESP"=20 a) What should be action taken if ISID received in PATH message is not configured? Do I need to send PATH ERR message? =20 Then the ISID should be "dynamically" configured to an appropriate CBP that is connected to the CNP. =20 b) Assuming that I have received more than one ISID and each one belong to different CBP port, in such case what should be the behavior?=20 This should not happen provided the path computation and the service (ISID) allocation is done properly.=20 In case it would happen, one can try to reconfigure the CBP ISID allocations on the egress, if this is not possible then an error should be raised and sent in Path_Err. I couldn't find a good error value for this on the registry, if we want to account for this case explicitly we possibly need a new error value Routing Problem / Invalid Service ID =20 I am doing the manual configuration and association of ISID to CBP. Regards Choudarypally ------_=_NextPart_001_01CA5671.0506AE2B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Choudarypally,
Please=20 see inline.
Thanks=20 and best regards,
Attila

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of=20 choudarypally.subramanyam@wipro.com
Sent: Thursday, = October 22,=20 2009 1:51 AM
To: ccamp@ietf.org
Subject: [CCAMP]=20 draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt- regardingISID error=20 handling

Hi ,

I am currently working on draft=20 “draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt” and I = write this email to seek=20 some help from experts. I have two questions regarding the Section 3 = paragraph=20 6.

1) It say “An IB-BEB receiving a PATH message specifying=20 one
   of its CNPs can locally determine which CBPs have=20 internal
   connectivity to the I-component supporting = the given=20 CNP.”

How does the CSPF function select egress CNP, based on what=20 criteria?  

 

The CNP is the port to which clients of the PBB-TE domain = are=20 connected to. CSPF should consider which clients the Eth-LSP is meant to = support.

2) Further it says “On the other hand, if there is = information=20 on
   the service (I-SID) that the given ESP will = support, then=20 the IB-BEB
   MUST first determine which PIP and CBP is=20 configured with the I-SID
   and MUST assign that CBP to = the ESP”=20

a) What should be action taken if ISID received in PATH = message is not=20 configured? Do I need to send PATH ERR message?  

Then the ISID should be "dynamically" configured to an = appropriate=20 CBP that is connected to the CNP.

 
b) Assuming = that I=20 have received more than one ISID and each one belong to different CBP = port, in=20 such case what should be the behavior? 

This should not happen provided the path = computation and=20 the service (ISID) allocation is done properly.

In case it would happen, one can try to reconfigure the CBP = ISID=20 allocations on the egress, if this is not possible then an error should = be=20 raised and sent in Path_Err. I couldn't find a good error value for = this on=20 the registry, if we want to account for this case explicitly = we possibly=20 need a new error value  Routing Problem / Invalid Service=20 ID

 

 I am doing the manual configuration and association of ISID = to=20 CBP.

Regards
Choudarypally

------_=_NextPart_001_01CA5671.0506AE2B-- From Donald.Fedyk@alcatel-lucent.com Mon Oct 26 12:59:51 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9323F3A6873 for ; Mon, 26 Oct 2009 12:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+9oxEWiKAI0 for ; Mon, 26 Oct 2009 12:59:45 -0700 (PDT) Received: from audl751.usa.alcatel.com (audl751.usa.alcatel.com [143.209.238.164]) by core3.amsl.com (Postfix) with ESMTP id 5244128C345 for ; Mon, 26 Oct 2009 12:59:28 -0700 (PDT) Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id n9QJxcmm003419; Mon, 26 Oct 2009 13:59:39 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.9]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 14:59:38 -0500 Received: from USDALSMBS05.ad3.ad.alcatel.com ([172.22.216.34]) by USDALSMBS03.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 14:59:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5676.D5B0D3AC" Date: Mon, 26 Oct 2009 14:59:31 -0500 Message-ID: <292BD6E016C29243BB231D329D626C8C030671A2@USDALSMBS05.ad3.ad.alcatel.com> In-Reply-To: <53CCFDD6E346CB43994852666C210E9108BF9B77@esealmw116.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt-regardingISID error handling Thread-Index: AcpSqVK+wd2bKaYBS7qAjTlddLDxQgDwbG/AAAGu7XA= References: <53CCFDD6E346CB43994852666C210E9108BF9B77@esealmw116.eemea.ericsson.se> From: "FEDYK Don" To: "Attila Takacs" , X-OriginalArrivalTime: 26 Oct 2009 19:59:34.0793 (UTC) FILETIME=[D7129790:01CA5676] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 Cc: ccamp@ietf.org Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt-regardingISID error handling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 19:59:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5676.D5B0D3AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi=20 Thanks Attila A bit of clarification. (Hopefully)=20 ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Attila Takacs Sent: Monday, October 26, 2009 3:18 PM To: choudarypally.subramanyam@wipro.com Cc: ccamp@ietf.org Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt-regardingISID error handling =09 =09 Hi Choudarypally, Please see inline. Thanks and best regards, Attila ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of choudarypally.subramanyam@wipro.com Sent: Thursday, October 22, 2009 1:51 AM To: ccamp@ietf.org Subject: [CCAMP] draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt- regardingISID error handling =09 =09 Hi , I am currently working on draft "draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt" and I write this email to seek some help from experts. I have two questions regarding the Section 3 paragraph 6. 1) It say "An IB-BEB receiving a PATH message specifying one of its CNPs can locally determine which CBPs have internal connectivity to the I-component supporting the given CNP." How does the CSPF function select egress CNP, based on what criteria? =20 =20 The CNP is the port to which clients of the PBB-TE domain are connected to. CSPF should consider which clients the Eth-LSP is meant to support.=20 The Customer network port(s) CNP are the ones that are associated with the Customer Backbone Port PBB-TE MAC address. We are really only signaling A TE service instance. A TE service instance is supported by two point-to-point ESPs where the ESPs' endpoints have the same CBP MAC addresses. =20 2) Further it says "On the other hand, if there is information on the service (I-SID) that the given ESP will support, then the IB-BEB MUST first determine which PIP and CBP is configured with the I-SID and MUST assign that CBP to the ESP"=20 a) What should be action taken if ISID received in PATH message is not configured? Do I need to send PATH ERR message? =20 Then the ISID should be "dynamically" configured to an appropriate CBP that is connected to the CNP.=20 At one point we were considering signaling I-SID information. However I believe we removed that from the document. I-SIDs should be configured locally and should be consistent but the signaling does not carry this information. It is purely up to the local implementation to use I-SIDs. So multiple I-SIDs could go to several CNPs (one or more each).=20 b) Assuming that I have received more than one ISID and each one belong to different CBP port, in such case what should be the behavior?=20 This should not happen provided the path computation and the service (ISID) allocation is done properly.=20 In case it would happen, one can try to reconfigure the CBP ISID allocations on the egress, if this is not possible then an error should be raised and sent in Path_Err. I couldn't find a good error value for this on the registry, if we want to account for this case explicitly we possibly need a new error value Routing Problem / Invalid Service ID=20 Since we don't signal I-SIDs I'm having a hard time parsing this scenario.=20 Don=20 =20 =20 I am doing the manual configuration and association of ISID to CBP. Regards Choudarypally ------_=_NextPart_001_01CA5676.D5B0D3AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
Thanks=20 Attila
A bit of clarification. = (Hopefully)=20

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of Attila=20 Takacs
Sent: Monday, October 26, 2009 3:18 PM
To:=20 choudarypally.subramanyam@wipro.com
Cc:=20 ccamp@ietf.org
Subject: Re: [CCAMP]=20 draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt-regardingISID error=20 handling

Hi Choudarypally,
Please see inline.
Thanks and best regards,
Attila

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of=20 choudarypally.subramanyam@wipro.com
Sent: Thursday, = October=20 22, 2009 1:51 AM
To: ccamp@ietf.org
Subject: = [CCAMP]=20 draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt- regardingISID error=20 handling

Hi ,

I am currently working on draft=20 “draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt” and I = write this email to=20 seek some help from experts. I have two questions regarding the = Section 3=20 paragraph 6.

1) It say “An IB-BEB receiving a PATH message specifying=20 one
   of its CNPs can locally determine which CBPs = have=20 internal
   connectivity to the I-component supporting = the=20 given CNP.”

How does the CSPF function select egress CNP, based on what=20 criteria?  

 

The CNP is the port to which = clients of the=20 PBB-TE domain are connected to. CSPF should consider which clients the = Eth-LSP=20 is meant to support. 

<= /BLOCKQUOTE>

The=20 Customer network port(s) CNP are the ones that are associated with=20 the Customer Backbone Port PBB-TE MAC address.  We are really = only=20 signaling A TE service instance.  A TE service instance is = supported by two=20 point-to-point
ESPs where the ESPs' endpoints have the same CBP MAC=20 addresses.

 

2) Further it says “On the other hand, if there is = information=20 on
   the service (I-SID) that the given ESP will = support, then=20 the IB-BEB
   MUST first determine which PIP and CBP is = configured with the I-SID
   and MUST assign that CBP = to the=20 ESP”

a) What should be action taken if ISID received in PATH = message is=20 not configured? Do I need to send PATH ERR message?  

Then the ISID should be "dynamically" = configured=20 to an appropriate CBP that is connected to the CNP. 

<= /BLOCKQUOTE>

At one point = we were=20 considering signaling I-SID information. However I believe we removed = that from=20 the document.  I-SIDs should be configured locally and should = be=20 consistent but the signaling does not carry this information.  It = is purely=20 up to the local implementation to use I-SIDs.  So multiple I-SIDs = could go=20 to several CNPs (one or more each).=20
b) Assuming that I have = received=20 more than one ISID and each one belong to different CBP port, in such = case what=20 should be the behavior? 

This should not happen provided the path = computation and=20 the service (ISID) allocation is done properly.

In case it would happen, one can try to = reconfigure=20 the CBP ISID allocations on the egress, if this is not possible then = an error=20 should be raised and sent in Path_Err. I couldn't find a good = error value=20 for this on the registry, if we want to account for this case = explicitly=20 we possibly need a new error value  Routing Problem / = Invalid=20 Service ID 

<= /BLOCKQUOTE>

Since we don't = signal I-SIDs=20 I'm having a hard time parsing this scenario.=20

Don=20

 

 

 I am doing the manual configuration and association of ISID = to=20 CBP.

=

Regards
Choudarypally

------_=_NextPart_001_01CA5676.D5B0D3AC-- From loa@pi.nu Mon Oct 26 13:49:47 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E3663A67CC; Mon, 26 Oct 2009 13:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXlAejU9pMzU; Mon, 26 Oct 2009 13:49:46 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 959F13A6781; Mon, 26 Oct 2009 13:49:46 -0700 (PDT) Received: from [38.109.153.43] (unknown [38.109.153.43]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 0E0CED404F; Mon, 26 Oct 2009 21:49:56 +0100 (CET) Message-ID: <4AE60B70.6090603@pi.nu> Date: Mon, 26 Oct 2009 21:49:52 +0100 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" , mpls@ietf.org, pwe3@ietf.org, ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 20:49:47 -0000 All, this is to start a two week poll in making draft-swallow-mpls-tp-identifiers-02.txt an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. The poll ends Sun Nov 8. /Loa MPLS WG co-chair -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From choudarypally.subramanyam@wipro.com Mon Oct 26 14:37:20 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF8428C17C for ; Mon, 26 Oct 2009 14:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.143 X-Spam-Level: X-Spam-Status: No, score=-1.143 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBIQeuFQy6RY for ; Mon, 26 Oct 2009 14:37:14 -0700 (PDT) Received: from wipro-blr-out01.wipro.com (wipro-blr-out01.wipro.com [203.91.198.74]) by core3.amsl.com (Postfix) with ESMTP id A93C128C2BB for ; Mon, 26 Oct 2009 14:37:13 -0700 (PDT) X-AuditID: cb5bdd57-b7c19ae000000cb0-c7-4ae6169338f9 Received: from blr-ec-aa03.wipro.com ( [10.201.18.42]) by (Symantec Mail Security) with SMTP id F2.12.03248.39616EA4; Tue, 27 Oct 2009 03:07:23 +0530 (IST) Received: from blr-ec-bh02.wipro.com ([10.201.50.92]) by blr-ec-aa03.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 03:07:23 +0530 Received: from blr-ec-bh03.wipro.com ([10.201.50.97]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 03:07:22 +0530 Received: from HYD-MDP-MBX01.wipro.com ([10.150.50.181]) by blr-ec-bh03.wipro.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 03:07:01 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5684.7346753F" Date: Tue, 27 Oct 2009 03:07:00 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt- regardingISID error handling Thread-Index: AcpSqVK+wd2bKaYBS7qAjTlddLDxQgDwbG/AAAXKzx4= References: <53CCFDD6E346CB43994852666C210E9108BF9B77@esealmw116.eemea.ericsson.se> From: To: X-OriginalArrivalTime: 26 Oct 2009 21:37:01.0722 (UTC) FILETIME=[741D27A0:01CA5684] X-Brightmail-Tracker: AAAAAA== Cc: ccamp@ietf.org Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt- regardingISID error handling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:37:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5684.7346753F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you Attila for the responses. I have some further comments inline. ________________________________ From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] Sent: Tue 10/27/2009 12:47 AM To: Choudarypally Subramanyam (WT01 - Telecom Equipment) Cc: ccamp@ietf.org Subject: RE: [CCAMP] draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt- = regardingISID error handling Hi Choudarypally, Please see inline. Thanks and best regards, Attila ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of choudarypally.subramanyam@wipro.com Sent: Thursday, October 22, 2009 1:51 AM To: ccamp@ietf.org Subject: [CCAMP] draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt- = regardingISID error handling =09 =09 Hi , I am currently working on draft = "draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt" and I write this email = to seek some help from experts. I have two questions regarding the = Section 3 paragraph 6. 1) It say "An IB-BEB receiving a PATH message specifying one of its CNPs can locally determine which CBPs have internal connectivity to the I-component supporting the given CNP." How does the CSPF function select egress CNP, based on what criteria? =20 =20 The CNP is the port to which clients of the PBB-TE domain are connected = to. CSPF should consider which clients the Eth-LSP is meant to support. [Choudarypally] I will try to rephrase the question, What should the = constraints be for the ingress CSPF to correctly identify the egress CNP = while creating the PATH message? As I understand the CSPF will ONLY have = the complete PNP links and CNP TE links database, but ingress CSPF will = not know about the ISID to CNP mappings on the egress. In which case = ingress CSPF will not be able to identify the clients meant for Eth-LSP. 2) Further it says "On the other hand, if there is information on the service (I-SID) that the given ESP will support, then the IB-BEB MUST first determine which PIP and CBP is configured with the I-SID and MUST assign that CBP to the ESP"=20 a) What should be action taken if ISID received in PATH message is not = configured? Do I need to send PATH ERR message? =20 Then the ISID should be "dynamically" configured to an appropriate CBP = that is connected to the CNP. [Choudarypally] As I understand the ISIDs should be created by provider = based on the agreement with the customer. Not sure if the ISIDs can be = created dynamically based on signaling. Please let me know what you = think about this. =09 b) Assuming that I have received more than one ISID and each one belong = to different CBP port, in such case what should be the behavior?=20 This should not happen provided the path computation and the service = (ISID) allocation is done properly.=20 In case it would happen, one can try to reconfigure the CBP ISID = allocations on the egress, if this is not possible then an error should = be raised and sent in Path_Err. I couldn't find a good error value for = this on the registry, if we want to account for this case explicitly we = possibly need a new error value Routing Problem / Invalid Service ID [Choudarypally] I agree that this should not happen but in case the ISID = to CBP mapping on egress (which is done manually by operator based on = service agreement) is misconfigured. So the dynamic reconfiguration of = ISID to CBP may not be a good option. Ideally a PATH ERR should be = generated with appropriate error code. =20 I am doing the manual configuration and association of ISID to CBP. Regards Choudarypally ------_=_NextPart_001_01CA5684.7346753F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
Thank you = Attila for the responses. I have some further comments = inline.
=0A=

=0A=
=0A= From: Attila Takacs = [mailto:Attila.Takacs@ericsson.com]
Sent: Tue 10/27/2009 12:47 = AM
To: Choudarypally Subramanyam (WT01 - Telecom = Equipment)
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] = draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt- regardingISID error = handling

=0A=
=0A=
Hi Choudarypally,
=0A=
Please see inline.
=0A=
Thanks and best regards,
=0A=
Attila

=0A=
=0A=
=0A=
=0A= From: ccamp-bounces@ietf.org = [mailto:ccamp-bounces@ietf.org] On Behalf Of = choudarypally.subramanyam@wipro.com
Sent: Thursday, = October 22, 2009 1:51 AM
To: ccamp@ietf.org
Subject: = [CCAMP] draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt- regardingISID = error handling

=0A=
=0A=

Hi ,

=0A=

I am currently working on draft = “draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt” and I write = this email to seek some help from experts. I have two questions = regarding the Section 3 paragraph 6.

=0A=

1) It say “An IB-BEB receiving a PATH message specifying = one
   of its CNPs can locally determine which CBPs have = internal
   connectivity to the I-component supporting the = given CNP.”

=0A=

How does the CSPF function select egress CNP, based on what = criteria?  

=0A=

 

=0A=

The CNP is the port to which clients of the = PBB-TE domain are connected to. CSPF should consider which clients the = Eth-LSP is meant to support.

=0A=

[Choudarypally] I will try to rephrase the = question, What should the constraints be for the ingress CSPF to = correctly identify the egress CNP while creating the PATH message? As I = understand the CSPF will ONLY have the complete PNP links and CNP TE = links database, but ingress CSPF will not know about the ISID to = CNP mappings on the egress. In which case ingress CSPF will not = be able to identify the clients meant = for Eth-LSP.

=0A=
=0A=

2) Further it says “On the other hand, if there is information = on
   the service (I-SID) that the given ESP will support, = then the IB-BEB
   MUST first determine which PIP and CBP = is configured with the I-SID
   and MUST assign that CBP to = the ESP”

=0A=

a) What should be action taken if ISID received in PATH message = is not configured? Do I need to send PATH ERR message?  

=0A=

Then the ISID should be "dynamically" configured = to an appropriate CBP that is connected to the = CNP.

=0A=

[Choudarypally] As I understand = the ISIDs should be created by provider based on the agreement with the = customer. Not sure if the ISIDs can be = created dynamically based on signaling. Please let me know what you = think about this.

=0A=
=0A=


b) Assuming that I = have received more than one ISID and each one belong to different CBP = port, in such case what should be the behavior? 

=0A=

This should not = happen provided the path computation and the service = (ISID) allocation is done properly.

=0A=

In case it would happen, one can try to = reconfigure the CBP ISID allocations on the egress, if this is not = possible then an error should be raised and sent in Path_Err. I = couldn't find a good error value for this on the registry, if we want to = account for this case explicitly we possibly need a new error = value  Routing Problem / Invalid Service ID

=0A=

[Choudarypally] I agree that this should not happen but in = case the ISID to CBP mapping on egress (which is done manually by = operator based on service agreement) is misconfigured. So the dynamic = reconfiguration of ISID to CBP may not be a good option. Ideally a PATH = ERR should be generated with appropriate error = code.

=0A=
=0A=

 

=0A=

 I am doing the manual configuration and association of ISID to = CBP.

=0A=

Regards
Choudarypally

------_=_NextPart_001_01CA5684.7346753F-- From llevrau@alcatel-lucent.com Mon Oct 26 14:22:00 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97EB28C28B; Mon, 26 Oct 2009 14:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tq087QrzmYTG; Mon, 26 Oct 2009 14:21:59 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 8BA2428C181; Mon, 26 Oct 2009 14:21:58 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9QLMAGg008363 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 26 Oct 2009 22:22:10 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 26 Oct 2009 22:22:10 +0100 From: "LEVRAU, LIEVEN (LIEVEN)" To: Loa Andersson , "mpls-tp@ietf.org" , "mpls@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Date: Mon, 26 Oct 2009 22:22:26 +0100 Thread-Topic: [mpls-tp] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft Thread-Index: AcpWfeuB1DAoQZ3GTT6PxAgvXRRyqwABFHEA Message-ID: References: <4AE60B70.6090603@pi.nu> In-Reply-To: <4AE60B70.6090603@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 X-Mailman-Approved-At: Mon, 26 Oct 2009 15:36:35 -0700 Subject: Re: [CCAMP] [mpls-tp] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:22:00 -0000 Yes support. ./ Lieven -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Loa Andersson Sent: 26 October 2009 21:50 To: mpls-tp@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org Subject: [mpls-tp] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg = draft All, this is to start a two week poll in making draft-swallow-mpls-tp-identifiers-02.txt an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. The poll ends Sun Nov 8. /Loa MPLS WG co-chair --=20 Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From zali@cisco.com Mon Oct 26 15:58:12 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43A13A690C; Mon, 26 Oct 2009 15:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tyL2o2PZlid; Mon, 26 Oct 2009 15:58:12 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ECC4C3A6838; Mon, 26 Oct 2009 15:58:11 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFfG5UqrRN+K/2dsb2JhbADBYZdRAoQ9BIFe X-IronPort-AV: E=Sophos;i="4.44,628,1249257600"; d="scan'208";a="418374408" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2009 22:58:25 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n9QMwPxf000333; Mon, 26 Oct 2009 22:58:25 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 18:58:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Oct 2009 18:57:33 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] [mpls-tp] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft Thread-Index: AcpWfeuB1DAoQZ3GTT6PxAgvXRRyqwABFHEAAANTFeA= References: <4AE60B70.6090603@pi.nu> From: "Zafar Ali (zali)" To: "Loa Andersson" , , , , X-OriginalArrivalTime: 26 Oct 2009 22:58:25.0371 (UTC) FILETIME=[D2FEDAB0:01CA568F] Subject: Re: [CCAMP] [mpls-tp] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 22:58:12 -0000 yes/ support.=20 Thanks Regards... Zafar=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: 26 October 2009 21:50 > To: mpls-tp@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: [mpls-tp] poll on=20 > draft-swallow-mpls-tp-identifiers-02.txt for wg draft >=20 > All, >=20 > this is to start a two week poll in making >=20 > draft-swallow-mpls-tp-identifiers-02.txt >=20 > an MPLS working group document. >=20 > Send a mail to the mpls-tp@ietf.org mailing list, indicating=20 > "yes/support" or "no/do not support". >=20 > Comments on the content of the draft should be sent to the=20 > same mailing list with a different subject line. >=20 > The poll ends Sun Nov 8. >=20 > /Loa >=20 > MPLS WG co-chair >=20 >=20 > --=20 >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92=20 > 13 _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 From lberger@labn.net Mon Oct 26 16:07:19 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32E428C1A1 for ; Mon, 26 Oct 2009 16:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hiwT3PHAvrL for ; Mon, 26 Oct 2009 16:07:19 -0700 (PDT) Received: from outbound-mail-34.bluehost.com (outbound-mail-34.bluehost.com [69.89.18.154]) by core3.amsl.com (Postfix) with SMTP id 2EC9728C333 for ; Mon, 26 Oct 2009 16:07:19 -0700 (PDT) Received: (qmail 27277 invoked by uid 0); 26 Oct 2009 23:07:33 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy2.bluehost.com with SMTP; 26 Oct 2009 23:07:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=HfIJSsb/M0uCvxUhFh6zUtmI9yAa3PT3TQTbdjhljG84NAlSkG6qMhc638RNKjtyvKcUh7PO42vKjcwHOsviqVhxYomX9fgIeBBVtLPwsN8j5tvkvwjRSq/GyIxz0i8d; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N2Yey-00032H-Op for ccamp@ietf.org; Mon, 26 Oct 2009 17:07:32 -0600 Message-ID: <4AE62BC1.2070103@labn.net> Date: Mon, 26 Oct 2009 19:07:45 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 0.96a 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] Communication from OIF - October 22, 2009 (1 of 2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 23:07:20 -0000 The following was sent to the CCAMP WG chairs on October 22, 2009. A URL to the original communication (pdf) can be found below. The text in the communication is also enclosed. Lou ------------------------------------------------------------------ [http://trac.tools.ietf.org/wg/ccamp/trac/attachment/wiki/CommsLiasons/091022a-OIF.pdf] Mr. Lou Berger, lberger@labn.net, CCAMP Co-Chair Ms. Deborah Brungard, dbrungard@att.com, CCAMP Co-Chair Dear Lou and Deborah, OIF has been informed through its liaison with IETF CCAMP of your request for Internet Drafts that provide more detail on issues identified in OIF liaisons on support of ASON routing and Inverse Multiplexing. Following up on this, a number of OIF member participants have volunteered to develop Internet Drafts for submission to IETF CCAMP at its next meeting. Drafts have been created on: - ASON Routing implementation experience - Additional Functions for ASON Routing - Support of Inverse Multiplexing In keeping with IETF processes, these will be submitted as individual submissions from the draft authors, and do not represent formal products or agreements of the OIF. However, the drafts have been presented at the recent OIF meeting and are the result of discussion and testing within OIF. We request the consideration of these drafts by IETF CCAMP as potential Working Group activities and would support future work by IETF CCAMP in this area. Best regards, Lyndon Ong OIF Technical Committee chair cc: Ross Callon (rcallon@juniper.net) and Adrian Farrel (adrian.farrel@huawei.com), IETF Routing Area Directors; Acee Lindem (acee@redback.com) and Abhay Roy (akr@cisco.com), IETF OSPF WG co-chairs From lberger@labn.net Mon Oct 26 16:07:24 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2336628C3A7 for ; Mon, 26 Oct 2009 16:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.973 X-Spam-Level: X-Spam-Status: No, score=-1.973 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ip3n5elrW6eT for ; Mon, 26 Oct 2009 16:07:23 -0700 (PDT) Received: from outbound-mail-110.bluehost.com (outbound-mail-110.bluehost.com [69.89.22.10]) by core3.amsl.com (Postfix) with SMTP id 4C5F828C3B6 for ; Mon, 26 Oct 2009 16:07:23 -0700 (PDT) Received: (qmail 8183 invoked by uid 0); 26 Oct 2009 23:07:37 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy3.bluehost.com with SMTP; 26 Oct 2009 23:07:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Mfhs7GpzSlJEdQop/xWkIaNCoSlxrj+jLMWq+iRqFRcuMmvLzEeCF8MBvVazHyuOfYyqyPLfAcN7GPbviYWIw0eGf4HYsGwvv7XuLta4WbdDBK2Ezpi5KEa9eOpCwYk9; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N2Yf2-00033e-HK for ccamp@ietf.org; Mon, 26 Oct 2009 17:07:36 -0600 Message-ID: <4AE62BC5.3050701@labn.net> Date: Mon, 26 Oct 2009 19:07:49 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 0.96a 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} Subject: [CCAMP] Communication from OIF - October 22, 2009 (2 of 2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 23:07:24 -0000 The following was sent to the CCAMP WG chairs on October 22, 2009. A URL to the original communication (pdf) can be found below. The text in the communication is also enclosed. Lou ------------------------------------------------------------------ [http://trac.tools.ietf.org/wg/ccamp/trac/attachment/wiki/CommsLiasons/091022b-OIF.pdf] Mr. Lou Berger, lberger@labn.net, CCAMP Co-Chair Ms. Deborah Brungard, dbrungard@att.com, CCAMP Co-Chair Dear Lou and Deborah, OIF would like to bring the attention of IETF CCAMP to three specific issues identified in our liaison of July 23, 2009 on OIF Interop Demo Findings which have not yet generated a response from IETF CCAMP. The associated text in the July 23rd liaison was as follows: “Second, we found behaviour differences in error reporting and restoration triggering. Some implementations sent both Notify and PathErr detailing the fault location, others sent only Notify. Some implementations regarded the Notify as the trigger for restoration, others triggered on either message. Text in RFC 4872 section 11 indicates that the trigger is a "Notify and/or a PathErr". This text has been interpreted in different ways. Perhaps it could be clarified to indicate that either message individually, or the arrival of both messages within an interval, should be regarded as a single restoration trigger. Third, some implementations reported intermediate link failures using error code/sub-code 25/9 (Notify Error/LSP Failure) others 25/11 (Notify Error/LSP Locally Failed). RFC 4872 section 11 seems clear that 25/11 should be used to report an intermediate link failure for restoration. However, it seems strange not to trigger restoration procedures on receipt of errors that describe other faults. Fourth, some implementations used error code zero for administratively initiated graceful release of an LSP. We see that http://tools.ietf.org/html/draft-ietf-ccamp-mpls-graceful-shutdown-10#section-4.2 suggests error codes when the cause is link or node maintenance, but no suitable value exists to indicate an administrative LSP release for other reasons.” We welcome guidance from CCAMP on these three points. Thank you for your continued attention. Best regards, Lyndon Ong OIF Technical Committee chair cc: Ross Callon (rcallon@juniper.net) and Adrian Farrel (adrian.farrel@huawei.com) From zhang.fei3@zte.com.cn Mon Oct 26 18:48:39 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 350D528C17F; Mon, 26 Oct 2009 18:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.776 X-Spam-Level: X-Spam-Status: No, score=-95.776 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6zUwmDCl2c0; Mon, 26 Oct 2009 18:48:38 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 6108428C151; Mon, 26 Oct 2009 18:48:37 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111644429685300; Tue, 27 Oct 2009 09:22:17 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 14630.4803937422; Tue, 27 Oct 2009 09:36:55 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n9R1mfZA033807; Tue, 27 Oct 2009 09:48:41 +0800 (CST) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <4AE60B70.6090603@pi.nu> To: Loa Andersson MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 27 Oct 2009 09:48:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-10-27 09:48:37, Serialize complete at 2009-10-27 09:48:37 Content-Type: multipart/alternative; boundary="=_alternative 000A48124825765C_=" X-MAIL: mse2.zte.com.cn n9R1mfZA033807 Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, ccamp-bounces@ietf.org, "mpls-tp@ietf.org" Subject: Re: [CCAMP] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 01:48:39 -0000 This is a multipart message in MIME format. --=_alternative 000A48124825765C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U3VwcG9ydKOho6GjoQ0KDQpGZWkNCg0Ko7qjqQ0KDQoNCg0KTG9hIEFuZGVyc3NvbiA8bG9hQHBp Lm51PiANCreivP7IyzogIGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMDktMTAtMjcgMDQ6NDkN Cg0KytW8/sjLDQoibXBscy10cEBpZXRmLm9yZyIgPG1wbHMtdHBAaWV0Zi5vcmc+LCBtcGxzQGll dGYub3JnLCBwd2UzQGlldGYub3JnLCANCmNjYW1wQGlldGYub3JnDQqzrcvNDQoNCtb3zOINCltD Q0FNUF0gcG9sbCBvbiBkcmFmdC1zd2FsbG93LW1wbHMtdHAtaWRlbnRpZmllcnMtMDIudHh0IGZv ciB3ZyBkcmFmdA0KDQoNCg0KDQoNCg0KQWxsLA0KDQp0aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdl ZWsgcG9sbCBpbiBtYWtpbmcNCg0KZHJhZnQtc3dhbGxvdy1tcGxzLXRwLWlkZW50aWZpZXJzLTAy LnR4dA0KDQphbiBNUExTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoNClNlbmQgYSBtYWlsIHRv IHRoZSBtcGxzLXRwQGlldGYub3JnIG1haWxpbmcgbGlzdCwgaW5kaWNhdGluZw0KInllcy9zdXBw b3J0IiBvciAibm8vZG8gbm90IHN1cHBvcnQiLg0KDQpDb21tZW50cyBvbiB0aGUgY29udGVudCBv ZiB0aGUgZHJhZnQgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIHNhbWUNCm1haWxpbmcgbGlzdCB3aXRo IGEgZGlmZmVyZW50IHN1YmplY3QgbGluZS4NCg0KVGhlIHBvbGwgZW5kcyBTdW4gTm92IDguDQoN Ci9Mb2ENCg0KTVBMUyBXRyBjby1jaGFpcg0KDQoNCi0tIA0KDQoNCkxvYSBBbmRlcnNzb24gICAg ICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tDQpT ciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAgICBsb2FAcGkubnUNCkVy aWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAgICAgICAgcGhvbmU6ICs0NiAxMCA3MTcgNTIg MTMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArNDYgNzY3 IDcyIDkyIDEzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KDQoNCg0K --=_alternative 000A48124825765C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlN1cHBvcnSjoaOho6E8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZlaTwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+o7qjqTwvZm9udD4NCjxicj4N Cjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lk dGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Mb2EgQW5kZXJzc29uICZs dDtsb2FAcGkubnUmZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj63orz+yMs6ICZuYnNwO2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0xMC0yNyAwNDo0OTwvZm9udD4NCjx0 ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDttcGxz LXRwQGlldGYub3JnJnF1b3Q7ICZsdDttcGxzLXRwQGlldGYub3JnJmd0OywNCm1wbHNAaWV0Zi5v cmcsIHB3ZTNAaWV0Zi5vcmcsIGNjYW1wQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6z rcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bQ0NBTVBdIHBvbGwgb24gZHJhZnQt c3dhbGxvdy1tcGxzLXRwLWlkZW50aWZpZXJzLTAyLnR4dA0KZm9yIHdnICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2RyYWZ0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yPjx0dD5BbGwsPGJyPg0KPGJyPg0KdGhpcyBpcyB0byBzdGFydCBhIHR3 byB3ZWVrIHBvbGwgaW4gbWFraW5nPGJyPg0KPGJyPg0KZHJhZnQtc3dhbGxvdy1tcGxzLXRwLWlk ZW50aWZpZXJzLTAyLnR4dDxicj4NCjxicj4NCmFuIE1QTFMgd29ya2luZyBncm91cCBkb2N1bWVu dC48YnI+DQo8YnI+DQpTZW5kIGEgbWFpbCB0byB0aGUgbXBscy10cEBpZXRmLm9yZyBtYWlsaW5n IGxpc3QsIGluZGljYXRpbmc8YnI+DQomcXVvdDt5ZXMvc3VwcG9ydCZxdW90OyBvciAmcXVvdDtu by9kbyBub3Qgc3VwcG9ydCZxdW90Oy48YnI+DQo8YnI+DQpDb21tZW50cyBvbiB0aGUgY29udGVu dCBvZiB0aGUgZHJhZnQgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIHNhbWU8YnI+DQptYWlsaW5nIGxp c3Qgd2l0aCBhIGRpZmZlcmVudCBzdWJqZWN0IGxpbmUuPGJyPg0KPGJyPg0KVGhlIHBvbGwgZW5k cyBTdW4gTm92IDguPGJyPg0KPGJyPg0KL0xvYTxicj4NCjxicj4NCk1QTFMgV0cgY28tY2hhaXI8 YnI+DQo8YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+DQo8YnI+DQpMb2EgQW5kZXJzc29uICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb208 YnI+DQpTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsb2FAcGkubnU8YnI+DQpFcmljc3NvbiBJbmMgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Bob25lOiArNDYgMTAgNzE3IDUyIDEzPGJyPg0K ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOys0NiA3Njcg NzIgOTIgMTM8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCkNDQU1QIG1haWxpbmcgbGlzdDxicj4NCkNDQU1QQGlldGYub3JnPGJyPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4NCjxicj4NCjwvdHQ+ PC9mb250Pg0KPGJyPg0K --=_alternative 000A48124825765C_=-- From davari@broadcom.com Mon Oct 26 18:45:34 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4236B3A6890; Mon, 26 Oct 2009 18:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nrM0TVKCRY8; Mon, 26 Oct 2009 18:45:33 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 968363A6818; Mon, 26 Oct 2009 18:45:32 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 26 Oct 2009 18:44:06 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Mon, 26 Oct 2009 18:44:06 -0700 From: "Shahram Davari" To: "Loa Andersson" , "mpls-tp@ietf.org" , "mpls@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Date: Mon, 26 Oct 2009 18:44:04 -0700 Thread-Topic: [CCAMP] [mpls-tp] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft Thread-Index: AcpWfeuB1DAoQZ3GTT6PxAgvXRRyqwABFHEAAANTFeAABdf2MA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68157683B81@SJEXCHCCR02.corp.ad.broadcom.com> References: <4AE60B70.6090603@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 66F88FEC0UC27937264-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 27 Oct 2009 03:41:18 -0700 Subject: Re: [CCAMP] [mpls-tp] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 01:45:34 -0000 Support. -Shahram > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: 26 October 2009 21:50 > To: mpls-tp@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: [mpls-tp] poll on=20 > draft-swallow-mpls-tp-identifiers-02.txt for wg draft >=20 > All, >=20 > this is to start a two week poll in making >=20 > draft-swallow-mpls-tp-identifiers-02.txt >=20 > an MPLS working group document. >=20 > Send a mail to the mpls-tp@ietf.org mailing list, indicating=20 > "yes/support" or "no/do not support". >=20 > Comments on the content of the draft should be sent to the=20 > same mailing list with a different subject line. >=20 > The poll ends Sun Nov 8. >=20 > /Loa >=20 > MPLS WG co-chair >=20 >=20 > --=20 >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92=20 > 13 _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From lufang@cisco.com Mon Oct 26 21:19:15 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 254E43A69F4; Mon, 26 Oct 2009 21:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcYtsKBCaQdb; Mon, 26 Oct 2009 21:19:14 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 345853A63EB; Mon, 26 Oct 2009 21:19:14 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABsR5kqrR7H+/2dsb2JhbADAM5gEAoQ9BIFf X-IronPort-AV: E=Sophos;i="4.44,630,1249257600"; d="scan'208";a="261856076" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2009 04:19:28 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9R4JRIN004553; Tue, 27 Oct 2009 04:19:28 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 00:19:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 00:19:27 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [CCAMP] [mpls-tp] poll ondraft-swallow-mpls-tp-identifiers-02.txt for wg draft Thread-Index: AcpWfeuB1DAoQZ3GTT6PxAgvXRRyqwABFHEAAANTFeAAC0Id8A== References: <4AE60B70.6090603@pi.nu> From: "Luyuan Fang (lufang)" To: "Loa Andersson" , , , , X-OriginalArrivalTime: 27 Oct 2009 04:19:27.0840 (UTC) FILETIME=[AC525E00:01CA56BC] X-Mailman-Approved-At: Tue, 27 Oct 2009 03:41:18 -0700 Subject: Re: [CCAMP] [mpls] [mpls-tp] poll ondraft-swallow-mpls-tp-identifiers-02.txt for wg draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 04:19:15 -0000 Support. Luyuan > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: 26 October 2009 21:50 > To: mpls-tp@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: [mpls-tp] poll on > draft-swallow-mpls-tp-identifiers-02.txt for wg draft >=20 > All, >=20 > this is to start a two week poll in making >=20 > draft-swallow-mpls-tp-identifiers-02.txt >=20 > an MPLS working group document. >=20 > Send a mail to the mpls-tp@ietf.org mailing list, indicating=20 > "yes/support" or "no/do not support". >=20 > Comments on the content of the draft should be sent to the same=20 > mailing list with a different subject line. >=20 > The poll ends Sun Nov 8. >=20 > /Loa >=20 > MPLS WG co-chair >=20 >=20 > -- >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 > 13 _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From lufang@cisco.com Mon Oct 26 21:21:19 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920BE3A67D2; Mon, 26 Oct 2009 21:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAMwiW7CrXlQ; Mon, 26 Oct 2009 21:21:18 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 24F593A680C; Mon, 26 Oct 2009 21:21:18 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIQS5kpAZnwM/2dsb2JhbADAOJgDAoQ9BIFf X-IronPort-AV: E=Sophos;i="4.44,630,1249257600"; d="scan'208";a="65053650" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 27 Oct 2009 04:21:31 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9R4LViY024210; Tue, 27 Oct 2009 04:21:31 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 00:21:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 00:21:30 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [CCAMP] [mpls-tp] poll ondraft-swallow-mpls-tp-identifiers-02.txt for wg draft Thread-Index: AcpWfeuB1DAoQZ3GTT6PxAgvXRRyqwABFHEAAANTFeAAC0Id8AAAFYUg References: <4AE60B70.6090603@pi.nu> From: "Luyuan Fang (lufang)" To: "Loa Andersson" , , , , X-OriginalArrivalTime: 27 Oct 2009 04:21:31.0311 (UTC) FILETIME=[F5EA8BF0:01CA56BC] X-Mailman-Approved-At: Tue, 27 Oct 2009 03:41:19 -0700 Subject: Re: [CCAMP] [mpls] [mpls-tp] poll ondraft-swallow-mpls-tp-identifiers-02.txt for wg draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 04:21:19 -0000 yes/support. Luyuan=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: 26 October 2009 21:50 > To: mpls-tp@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: [mpls-tp] poll on > draft-swallow-mpls-tp-identifiers-02.txt for wg draft >=20 > All, >=20 > this is to start a two week poll in making >=20 > draft-swallow-mpls-tp-identifiers-02.txt >=20 > an MPLS working group document. >=20 > Send a mail to the mpls-tp@ietf.org mailing list, indicating=20 > "yes/support" or "no/do not support". >=20 > Comments on the content of the draft should be sent to the same=20 > mailing list with a different subject line. >=20 > The poll ends Sun Nov 8. >=20 > /Loa >=20 > MPLS WG co-chair >=20 >=20 > -- >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 > 13 _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From gregimirsky@gmail.com Tue Oct 27 03:48:09 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65C3D3A67E6; Tue, 27 Oct 2009 03:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTfBBHXoyKnO; Tue, 27 Oct 2009 03:48:08 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id BF60D3A6774; Tue, 27 Oct 2009 03:48:07 -0700 (PDT) Received: by fxm18 with SMTP id 18so6272fxm.37 for ; Tue, 27 Oct 2009 03:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=qBTu+shPZ4I2ELlaRnQGDFySxMCWeBg/OJiP9diFY2Q=; b=lZtErd8mqam9Ct1BmcyObG7SL8xDwNRqHm98qLpsyL9/rC/pCXu09MY/hRuA8UQX+U RjQKPY8zVU6f4arkqK2D3sfyLos3QRR30JF/0DrTtMP8NaN0mdgdM7ryK5o9EYvWwlI6 Nn3yhon3/OQoRoPlDhk5Tb8m6JIfAK8vQM9rM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LQD7Rr7/MNuH/yxSYRWNzO9/9g6QQ9khVuDjk30in7aKyWs7Bdl63Ek3ugBU2zN23Q LVRGq0AoB8oZFpIYxXxVL3jwBRa+fMya4oET8xfFtM8/oPfLdH/VApzDc+nyArDTpohq ykgJjAC6EIhkD42wbN1WsxBbUOPqtIMIUbZzM= MIME-Version: 1.0 Received: by 10.204.154.144 with SMTP id o16mr6535851bkw.213.1256640496861; Tue, 27 Oct 2009 03:48:16 -0700 (PDT) In-Reply-To: <4AE60B70.6090603@pi.nu> References: <4AE60B70.6090603@pi.nu> Date: Tue, 27 Oct 2009 03:48:16 -0700 Message-ID: <787be2780910270348wc847789jf7683ed613782605@mail.gmail.com> From: Greg Mirsky To: Loa Andersson Content-Type: multipart/alternative; boundary=0015175cb40a6d01880476e86a84 Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, "mpls-tp@ietf.org" Subject: Re: [CCAMP] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 10:48:09 -0000 --0015175cb40a6d01880476e86a84 Content-Type: text/plain; charset=ISO-8859-1 Yes+support Regards, Greg On Mon, Oct 26, 2009 at 1:49 PM, Loa Andersson wrote: > All, > > this is to start a two week poll in making > > draft-swallow-mpls-tp-identifiers-02.txt > > an MPLS working group document. > > Send a mail to the mpls-tp@ietf.org mailing list, indicating > "yes/support" or "no/do not support". > > Comments on the content of the draft should be sent to the same > mailing list with a different subject line. > > The poll ends Sun Nov 8. > > /Loa > > MPLS WG co-chair > > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --0015175cb40a6d01880476e86a84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes+support
Regards,
Greg

On Mon, O= ct 26, 2009 at 1:49 PM, Loa Andersson <loa@pi.nu> wrote:
All,

this is to start a two week poll in making

draft-swallow-mpls-tp-identifiers-02.txt

an MPLS working group document.

Send a mail to the mp= ls-tp@ietf.org mailing list, indicating
"yes/support" or "no/do not support".

Comments on the content of the draft should be sent to the same
mailing list with a different subject line.

The poll ends Sun Nov 8.

/Loa

MPLS WG co-chair


--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@eri= csson.com
Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 = 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +46 767 72 92 13
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp

--0015175cb40a6d01880476e86a84-- From eric.gray@ericsson.com Tue Oct 27 09:14:46 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8DC53A6359 for ; Tue, 27 Oct 2009 09:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxg8QfucaYvO for ; Tue, 27 Oct 2009 09:14:46 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 370B73A6A30 for ; Tue, 27 Oct 2009 09:14:33 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n9RGEfJe010976; Tue, 27 Oct 2009 11:14:45 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 11:14:14 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 11:14:13 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 27 Oct 2009 12:14:13 -0400 From: Eric Gray To: Lou Berger , CCAMP Date: Tue, 27 Oct 2009 12:14:12 -0400 Thread-Topic: [CCAMP] Communication from OIF - October 22, 2009 (2 of 2) Thread-Index: AcpWkUTHDzu6Nfy+Rs+9UVCJBZsMnQAf/jdw Message-ID: References: <4AE62BC5.3050701@labn.net> In-Reply-To: <4AE62BC5.3050701@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Oct 2009 16:14:13.0960 (UTC) FILETIME=[8670F480:01CA5720] Subject: Re: [CCAMP] Communication from OIF - October 22, 2009 (2 of 2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 16:14:47 -0000 Lou, On the reported issue with possible interpretation differences of the "Notify and/or a PathErr" text in RFC 4872: 1) We probably should have made it simpler for implementers by=20 explicitly specifying which of the two would be used. 2) Never-the-less, the text is reasonably clear - either a Notify, a PathErr, or both should be interpretted as a trigger. 3) Under this (IMO - correct) interpretation, implementations that trigger restoration only on the Notify, are not compliant with RFC 4872 - however, it is not clear that this is the behavior identified in the liaison (it seems likely that the issue is=20 with implementations that trigger twice because they get both messages, although it would be better if it were clear what=20 problems this leads to). 4) If the result of "triggering" on both messages is harmfull (it is not clear how creation of a duplicate "logging event" is something that should be considered "harmful"), it should be obvious to even the most casual implementer that a robust implementation might include a timer to prevent this from happening innappropriately. 5) This seems to come under the heading of "guidelines to building a robust implementation", which - if a remember correctly - is=20 not actually something we generally do in the IETF. On the reported issue with which errors should trigger a restoration, it is highly probable that restoration should only be triggered if doing so was the explicit intent of the entity sending an error message. In particular, it does not seem to be a good idea to trigger restoration based on a general error. -- Eric Gray -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L= ou Berger Sent: Monday, October 26, 2009 7:08 PM To: CCAMP Subject: [CCAMP] Communication from OIF - October 22, 2009 (2 of 2) The following was sent to the CCAMP WG chairs on October 22, 2009. A URL to the original communication (pdf) can be found below. The text in the communication is also enclosed. Lou ------------------------------------------------------------------ [http://trac.tools.ietf.org/wg/ccamp/trac/attachment/wiki/CommsLiasons/0910= 22b-OIF.pdf] Mr. Lou Berger, lberger@labn.net, CCAMP Co-Chair Ms. Deborah Brungard, dbrungard@att.com, CCAMP Co-Chair Dear Lou and Deborah, OIF would like to bring the attention of IETF CCAMP to three specific issues identified in our liaison of July 23, 2009 on OIF Interop Demo Findings which have not yet generated a response from IETF CCAMP. The associated text in the July 23rd liaison was as follows: "Second, we found behaviour differences in error reporting and restoration triggering. Some implementations sent both Notify and PathErr detailing the fault location, others sent only Notify. Some implementations regarded the Notify as the trigger for restoration, others triggered on either message. Text in RFC 4872 section 11 indicates that the trigger is a "Notify and/or a PathErr". This text has been interpreted in different ways. Perhaps it could be clarified to indicate that either message individually, or the arrival of both messages within an interval, should be regarded as a single restoration trigger. Third, some implementations reported intermediate link failures using error code/sub-code 25/9 (Notify Error/LSP Failure) others 25/11 (Notify Error/LSP Locally Failed). RFC 4872 section 11 seems clear that 25/11 should be used to report an intermediate link failure for restoration. However, it seems strange not to trigger restoration procedures on receipt of errors that describe other faults. Fourth, some implementations used error code zero for administratively initiated graceful release of an LSP. We see that http://tools.ietf.org/html/draft-ietf-ccamp-mpls-graceful-shutdown-10#secti= on-4.2 suggests error codes when the cause is link or node maintenance, but no suitable value exists to indicate an administrative LSP release for other reasons." We welcome guidance from CCAMP on these three points. Thank you for your continued attention. Best regards, Lyndon Ong OIF Technical Committee chair cc: Ross Callon (rcallon@juniper.net) and Adrian Farrel (adrian.farrel@huawei.com) _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From daniel@olddog.co.uk Tue Oct 27 09:43:37 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD4628C21B for ; Tue, 27 Oct 2009 09:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jaqONOUl7j5 for ; Tue, 27 Oct 2009 09:43:36 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 2E0C43A6A32 for ; Tue, 27 Oct 2009 09:43:31 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n9RGhOfB014165 for ; Tue, 27 Oct 2009 16:43:31 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id n9RGhLFE014147 for ; Tue, 27 Oct 2009 16:43:23 GMT From: "Daniel King" To: Date: Tue, 27 Oct 2009 16:43:22 -0000 Message-ID: <002601ca5724$9a0f65e0$ce2e31a0$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpXJJiD9LjYRjX4SceSgvrlTfowJQ== Content-Language: en-gb Subject: [CCAMP] New Wiki for the CCAMP Supplemental Information X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 16:43:37 -0000 Hello all, For you viewing pleasure, we have created a Wiki for the CCAMP Supplemental Information. This new Wiki replaces the previous CCAMP Supplemental Information site (http://ccamp.labn.net/). The Wiki can be accessed by clicking the "Wiki" link at the top of the IETF CCAMP Status Pages, or by going directly to the following URL: http://trac.tools.ietf.org/wg/ccamp/trac/wiki The new Wiki contains the following CCAMP Supplemental Information and links: - CCAMP Charter - Mailing List Archive - CCAMP Status Page (With document summary information and links to minutes) - Working group document issues/status list - Communications and Liaisons - Temporary Codepoint Registries Please feel free to send me, or the co-chairs, suggestions for new content or links for our Wiki. Best regards, Dan From lberger@labn.net Tue Oct 27 10:38:35 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1973A6A5F for ; Tue, 27 Oct 2009 10:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbyS8EUBXORy for ; Tue, 27 Oct 2009 10:38:34 -0700 (PDT) Received: from outbound-mail-305.bluehost.com (outbound-mail-305.bluehost.com [67.222.53.251]) by core3.amsl.com (Postfix) with SMTP id 40F133A67F3 for ; Tue, 27 Oct 2009 10:38:33 -0700 (PDT) Received: (qmail 32568 invoked by uid 0); 27 Oct 2009 17:38:46 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy6.bluehost.com with SMTP; 27 Oct 2009 17:38:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=p6tkR4dcOSV1QiorSnCFVDtAnYzQa72mb/euZIjbyYYWfKQmOROC6KXh3n5TrOiqny4cKfvrUt2Y342vSHzCd73yVjURApvoSCqJe3HwQph9q5xaaefLfBLK9fv9+GVR; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N2q0M-0000oQ-BM; Tue, 27 Oct 2009 11:38:46 -0600 Message-ID: <4AE73034.9050108@labn.net> Date: Tue, 27 Oct 2009 13:39:00 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Eric Gray References: <4AE62BC5.3050701@labn.net> In-Reply-To: X-Enigmail-Version: 0.96a 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] Communication from OIF - October 22, 2009 (2 of 2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 17:38:35 -0000 Eric, Thank you for your analysis. Please see below for responses/comments in-line. On 10/27/2009 12:14 PM, Eric Gray wrote: > Lou, > > On the reported issue with possible interpretation differences > of the "Notify and/or a PathErr" text in RFC 4872: > > 1) We probably should have made it simpler for implementers by > explicitly specifying which of the two would be used. I agree that the text could have been more explicit on the topic. That said, it could be either based on when Notify Request is used and the time of the messages. > 2) Never-the-less, the text is reasonably clear - either a Notify, > a PathErr, or both should be interpretted as a trigger. 100% agree. > 3) Under this (IMO - correct) interpretation, implementations that > trigger restoration only on the Notify, are not compliant with > RFC 4872 - however, it is not clear that this is the behavior > identified in the liaison Again, I agree. Furthermore, with regard to the text: "Some implementations sent both Notify and PathErr detailing the fault location, others sent only Notify." The ones that only sent Notifiy messages are clearly not following RFC 3473. > (it seems likely that the issue is > with implementations that trigger twice because they get both > messages, although it would be better if it were clear what > problems this leads to). > 4) If the result of "triggering" on both messages is harmfull (it > is not clear how creation of a duplicate "logging event" is > something that should be considered "harmful"), it should be > obvious to even the most casual implementer that a robust > implementation might include a timer to prevent this from > happening innappropriately. > 5) This seems to come under the heading of "guidelines to building > a robust implementation", which - if a remember correctly - is > not actually something we generally do in the IETF. > I agree with all the above. Furthermore, it's fairly easy to determine when on message matches the other. I think this all goes to the point that no matter how much detail is provided, someone will always want more. > On the reported issue with which errors should trigger a > restoration, it is highly probable that restoration should only > be triggered if doing so was the explicit intent of the entity > sending an error message. In particular, it does not seem to be > a good idea to trigger restoration based on a general error. > I think this is consistent with the current text in 4872. The other perspective, is that it may be useful to have error codes/values that are "more informative" while still triggering LSP Rerouting. I think this is a valid perspective, but it doesn't match current RFCs. (Now if someone want's to contribute a draft on this, we can consider changing this.) Thank you for the basis of a response (to OIF)! Lou > -- > Eric Gray > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Monday, October 26, 2009 7:08 PM > To: CCAMP > Subject: [CCAMP] Communication from OIF - October 22, 2009 (2 of 2) > > The following was sent to the CCAMP WG chairs on October 22, 2009. A > URL to the original communication (pdf) can be found below. The text in > the communication is also enclosed. > > Lou > ------------------------------------------------------------------ > [http://trac.tools.ietf.org/wg/ccamp/trac/attachment/wiki/CommsLiasons/091022b-OIF.pdf] > > > Mr. Lou Berger, lberger@labn.net, CCAMP Co-Chair > Ms. Deborah Brungard, dbrungard@att.com, CCAMP Co-Chair > > Dear Lou and Deborah, > > OIF would like to bring the attention of IETF CCAMP to three specific > issues identified in our liaison of July 23, 2009 on OIF Interop Demo > Findings which have not yet generated a response from IETF CCAMP. The > associated text in the July 23rd liaison was as follows: > > "Second, we found behaviour differences in error reporting and > restoration triggering. Some implementations > sent both Notify and PathErr detailing the fault location, others sent > only Notify. Some implementations > regarded the Notify as the trigger for restoration, others triggered on > either message. Text in RFC 4872 > section 11 indicates that the trigger is a "Notify and/or a PathErr". > This text has been interpreted in different > ways. Perhaps it could be clarified to indicate that either message > individually, or the arrival of both > messages within an interval, should be regarded as a single restoration > trigger. > > Third, some implementations reported intermediate link failures using > error code/sub-code 25/9 (Notify > Error/LSP Failure) others 25/11 (Notify Error/LSP Locally Failed). RFC > 4872 section 11 seems clear that > 25/11 should be used to report an intermediate link failure for > restoration. However, it seems strange not to > trigger restoration procedures on receipt of errors that describe other > faults. > > Fourth, some implementations used error code zero for administratively > initiated graceful release of an LSP. > We see that > http://tools.ietf.org/html/draft-ietf-ccamp-mpls-graceful-shutdown-10#section-4.2 > suggests error > codes when the cause is link or node maintenance, but no suitable value > exists to indicate an administrative > LSP release for other reasons." > > We welcome guidance from CCAMP on these three points. Thank you for your > continued attention. > > Best regards, > Lyndon Ong > OIF Technical Committee chair > > cc: Ross Callon (rcallon@juniper.net) and Adrian Farrel > (adrian.farrel@huawei.com) > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From fu.xihua@zte.com.cn Wed Oct 28 01:17:43 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50F63A68DB for ; Wed, 28 Oct 2009 01:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5XIOHfEHeiN for ; Wed, 28 Oct 2009 01:17:42 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 3AE203A686D for ; Wed, 28 Oct 2009 01:17:42 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 9110473195744; Wed, 28 Oct 2009 15:57:42 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 14630.2094925659; Wed, 28 Oct 2009 16:05:59 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n9S8HeqM091464; Wed, 28 Oct 2009 16:17:40 +0800 (CST) (envelope-from fu.xihua@zte.com.cn) To: zhangfatai@huawei.com, CCAMP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Wed, 28 Oct 2009 16:18:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-10-28 16:17:32, Serialize complete at 2009-10-28 16:17:32 Content-Type: multipart/alternative; boundary="=_alternative 002D8A984825765D_=" X-MAIL: mse1.zte.com.cn n9S8HeqM091464 Subject: Re: [CCAMP] OTN control drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 08:17:43 -0000 This is a multipart message in MIME format. --=_alternative 002D8A984825765D_= Content-Type: text/plain; charset="US-ASCII" Hi Fatai and All, There is also another draft about the ODUk extension which has been presented in IETF 75th meeting. It has been updated to draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-01.txt. Note: The name of this updated draft will be changed to draft-fuxh-ccamp-gmpls-extension-for-evolutive-otn-01.txt after 09, Nov. we'd appreciate your review and comments. Xihua Fu ZTE Corporation ----- Original Message ----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Fatai Zhang Sent: Friday, October 23, 2009 11:32 AM To: CCAMP Subject: [CCAMP] OTN control drafts Hi CCAMPers, You know that there are lots of interests from both a technical and organizational standpoint (e.g., ITU-T SG15/Q12,Q14, IETF CCAMP) on OTN control, since draft-zhang-ccamp-gmpls-evolving-g709-00.txt was presented in IETF 75th meeting. You also know that [G.709 V3] including ODU0, ODU4, ODUflex... was consented by ITU-T SG15 in this October. Therefore, in order to control and manage the OTN networks efficiently, OTN control is really important for the industry. Up to now, we have five drafts about OTN control: (1) draft-zhang-ccamp-gmpls-g709-framework-00.txt (2) draft-zhang-ccamp-gmpls-evolving-g709-03.txt (3) draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt (4) draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt (5) draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt To promote better understanding or the discussions in Hiroshima meeting, we'd appreciate your review and comments. Thanks Authors of these drafts _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --=_alternative 002D8A984825765D_= Content-Type: text/html; charset="US-ASCII"
Hi Fatai and All,

There is also another draft about the ODUk extension which has been presented in IETF 75th meeting. It has been updated to draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn-01.txt. Note: The name of this updated draft will be changed to draft-fuxh-ccamp-gmpls-extension-for-evolutive-otn-01.txt after 09, Nov.
we'd appreciate your review and comments.

Xihua Fu
ZTE Corporation

----- Original Message -----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Fatai Zhang
Sent: Friday, October 23, 2009 11:32 AM
To: CCAMP
Subject: [CCAMP] OTN control drafts
 
Hi CCAMPers,
 
You know that there are lots of interests from both a technical and organizational standpoint (e.g., ITU-T SG15/Q12,Q14, IETF CCAMP) on OTN control, since draft-zhang-ccamp-gmpls-evolving-g709-00.txt was presented in IETF 75th meeting.
 
You also know that [G.709 V3] including ODU0, ODU4, ODUflex... was consented by ITU-T SG15 in this October.  Therefore, in order to control and manage the OTN networks efficiently, OTN control is really important for the industry.
 
Up to now, we have five drafts about OTN control:
(1) draft-zhang-ccamp-gmpls-g709-framework-00.txt
(2) draft-zhang-ccamp-gmpls-evolving-g709-03.txt
(3) draft-ceccarelli-ccamp-gmpls-ospf-g709-00.txt
(4) draft-ceccarelli-ccamp-gmpls-g709-lmp-test-01.txt
(5) draft-zhang-ccamp-gmpls-g709-lmp-discovery-02.txt
 
To promote better understanding or the discussions in Hiroshima meeting, we'd appreciate your review and comments.
 
 
Thanks
 
Authors of these drafts
 
 _______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp --=_alternative 002D8A984825765D_=-- From wwwrun@core3.amsl.com Tue Oct 27 14:55:37 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7F0783A697F; Tue, 27 Oct 2009 14:55:36 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: dbrungard@att.com,lberger@labn.net, Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091027215537.7F0783A697F@core3.amsl.com> Date: Tue, 27 Oct 2009 14:55:37 -0700 (PDT) X-Mailman-Approved-At: Wed, 28 Oct 2009 04:05:24 -0700 Cc: hiroshi.ota@itu.int, greg.jones@itu.int, ccamp@ietf.org, yoichi.maeda@ntt-at.co.jp, peter.stassar@ties.itu.int, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, francesco.montalti@telecomitalia.it Subject: [CCAMP] New Liaison Statement, "LS78 - Lambda Switch Capable Equipment" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 21:55:37 -0000 Title: LS78 - Lambda Switch Capable Equipment Submission Date: 2009-10-27 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=602 From: Greg Jones(ITU-T SG 15) To: IETF CCAMP Working Group(dbrungard@att.com,lberger@labn.net,) Cc: paf@cisco.com adrian.farrel@huawei.com rcallon@juniper.net adrian.farrel@huawei.com ccamp@ietf.org yoichi.maeda@ntt-at.co.jp francesco.montalti@telecomitalia.it Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: peter.stassar@ties.itu.int Purpose: For information Body: Attachment(s): LS78 - Lambda Switch Capable Equipment - pdf (https://datatracker.ietf.org/documents/LIAISON/file718.pdf) From wwwrun@core3.amsl.com Tue Oct 27 15:09:43 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 81AD53A6A4A; Tue, 27 Oct 2009 15:09:43 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: dbrungard@att.com,lberger@labn.net Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091027220943.81AD53A6A4A@core3.amsl.com> Date: Tue, 27 Oct 2009 15:09:43 -0700 (PDT) X-Mailman-Approved-At: Wed, 28 Oct 2009 04:05:24 -0700 Cc: hiroshi.ota@itu.int, greg.jones@itu.int, ccamp@ietf.org, malcolm.betts@huawei.com, yoichi.maeda@ntt-at.co.jp, sjtrowbridge@alcatel-lucent.com, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int Subject: [CCAMP] New Liaison Statement, "LS86 - Comments on WSON Impairment Work in CCAMP" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 22:09:43 -0000 Title: LS86 - Comments on WSON Impairment Work in CCAMP Submission Date: 2009-10-27 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=603 Please reply by 2010-05-31 From: Greg Jones(ITU-T SG 15) To: IETF ccamp Working Group(dbrungard@att.com,lberger@labn.net) Cc: paf@cisco.com adrian.farrel@huawei.com rcallon@juniper.net ccamp@ietf.org yoichi.maeda@ntt-at.co.jp sjtrowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: malcolm.betts@huawei.com Purpose: For comment Body: Attachment(s): LS86 - Comments on WSON Impairment Work in CCAMP - pdf (https://datatracker.ietf.org/documents/LIAISON/file719.pdf) From wwwrun@core3.amsl.com Tue Oct 27 15:41:52 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id F121228C0D6; Tue, 27 Oct 2009 15:41:51 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: dbrungard@att.com, lberger@labn.net, jpv@cisco.com, julien.meuric@orange-ftgroup.com, swallow@cisco.com, loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091027224151.F121228C0D6@core3.amsl.com> Date: Tue, 27 Oct 2009 15:41:51 -0700 (PDT) X-Mailman-Approved-At: Wed, 28 Oct 2009 04:05:24 -0700 Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, ccamp@ietf.org, yoichi.maeda@ntt-at.co.jp, george_young@labs.att.com, sjtrowbridge@alcatel-lucent.com, pce@ietf.org, adrian.farrel@huawei.com, tsbsg15@itu.int, rcallon@juniper.net, paf@cisco.com Subject: [CCAMP] New Liaison Statement, "LS97 - SG15 OTNT Standardization Work Plan" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 22:41:52 -0000 Title: LS97 - SG15 OTNT Standardization Work Plan Submission Date: 2009-10-27 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=605 Please reply by 2010-04-30 From: Greg Jones(ITU-T SG 15) To: IETF (ccamp, pce and mpls WGs)(dbrungard@att.com,lberger@labn.net,jpv@cisco.com,julien.meuric@orange-ftgroup.com,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com adrian.farrel@huawei.com rcallon@juniper.net ccamp@ietf.org pce@ietf.org mpls@ietf.org yoichi.maeda@ntt-at.co.jp sjtrowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: george_young@labs.att.com koike.yoshinori@lab.ntt.co.jp Purpose: For comment Body: Attachment(s): LS97 - SG15 OTNT Standardization Work Plan - pdf (https://datatracker.ietf.org/documents/LIAISON/file721.pdf) LS97 - Draft Revised Optical Transport Networks & Technologies Standardization Work Plan, Issue 12 - pdf (https://datatracker.ietf.org/documents/LIAISON/file722.pdf) From wwwrun@core3.amsl.com Tue Oct 27 15:49:32 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 18EF928C0D0; Tue, 27 Oct 2009 15:49:31 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: dbrungard@att.com,lberger@labn.net, Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091027224932.18EF928C0D0@core3.amsl.com> Date: Tue, 27 Oct 2009 15:49:32 -0700 (PDT) X-Mailman-Approved-At: Wed, 28 Oct 2009 04:05:24 -0700 Cc: hiroshi.ota@itu.int, greg.jones@itu.int, ccamp@ietf.org, malcolm.betts@huawei.com, yoichi.maeda@ntt-at.co.jp, sjtrowbridge@alcatel-lucent.com, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int Subject: [CCAMP] New Liaison Statement, "LS100 - Enhancements to the OTN" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 22:49:32 -0000 Title: LS100 - Enhancements to the OTN Submission Date: 2009-10-27 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=606 From: Greg Jones(ITU-T SG 15) To: IETF ccamp working group(dbrungard@att.com,lberger@labn.net,) Cc: paf@cisco.com adrian.farrel@huawei.com rcallon@juniper.net ccamp@ietf.org yoichi.maeda@ntt-at.co.jp sjtrowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: malcolm.betts@huawei.com Purpose: For information Body: Attachment(s): LS100 - Enhancements to the OTN - pdf (https://datatracker.ietf.org/documents/LIAISON/file723.pdf) From nurit.sprecher@nsn.com Wed Oct 28 09:36:50 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C423A6A1F for ; Wed, 28 Oct 2009 09:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unl8CmCMQk8l for ; Wed, 28 Oct 2009 09:36:38 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 4B65428C247 for ; Wed, 28 Oct 2009 09:36:36 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9SGaQcs004301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Oct 2009 17:36:26 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9SGaNDx008896; Wed, 28 Oct 2009 17:36:26 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 17:36:23 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA57EC.C91350A7" Date: Wed, 28 Oct 2009 17:36:20 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A532640173CAF7@DEMUEXC014.nsn-intra.net> In-Reply-To: <04bb01ca563b$a414db90$704c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt Thread-Index: AcpWPJxe+HpqXCSHTLiXNb8HVdpkDwBr6GZQ References: <077E41CFFD002C4CAB7DFA4386A532640167C3E9@DEMUEXC014.nsn-intra.net> <465531011AE4654BA0D30D01AB9EAA6E449EB8@FIESEXC030.nsn-intra.net> <328B9F5068825A48A4B8422A350B9047BC9D1E@CNBEEXC006.nsn-intra.net> <077E41CFFD002C4CAB7DFA4386A53264016B2EC2@DEMUEXC014.nsn-intra.net> <465531011AE4654BA0D30D01AB9EAA6E44A127@FIESEXC030.nsn-intra.net> <077E41CFFD002C4CAB7DFA4386A53264016DE8D7@DEMUEXC014.nsn-intra.net> <04c101ca53b4$1164ae30$704c460a@china.huawei.com> <077E41CFFD002C4CAB7DFA4386A532640170D04C@DEMUEXC014.nsn-intra.net> <04bb01ca563b$a414db90$704c460a@china.huawei.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Fatai Zhang" X-OriginalArrivalTime: 28 Oct 2009 16:36:23.0433 (UTC) FILETIME=[C9482F90:01CA57EC] Cc: "Clemens, Rainer \(NSN - DE/Munich\)" , "Soininen, Jonne \(NSN - FI/Espoo\)" , CCAMP Subject: Re: [CCAMP] I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:36:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA57EC.C91350A7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fatai, I think that in the IETF we should only put things in the normative part of the document that is also normative in ITU-T, i.e. in this case only what is written in the normative sections in G.709.=20 Everything in G.Sup43 can go into an appendix, i.e. mappings of 4x ODU2e into ODU3e1/2 and even OTU2e line signals. We should also mention what is the actual status of the G.sup43.=20 Other things that are being discussed in ITU-T and are not approved should stay completely out. Best regards, Nurit=20 ________________________________ From: ext Fatai Zhang [mailto:zhangfatai@huawei.com]=20 Sent: Monday, October 26, 2009 2:56 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: Clemens, Rainer (NSN - DE/Munich); CCAMP; Soininen, Jonne (NSN - FI/Espoo); Li Dan; han jianrui; lihan@chinamobile.com Subject: Re: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt Hi Nurit, =20 Thanks for your further comments. =20 We think we can move the content of G.sup43 to an appendix ( just for information), and explain that this part of information is not consented by ITU-T SG15. =20 We can also remove this appendix later, if this draft is ready to be RFC and the content of G.sup43 is still not consented (i.e., non-standard). =20 Is it OK for you? :-)~~~~, If Yes, we will reflect it in the next version. =20 =20 =20 Thanks =20 Fatai =20 Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message -----=20 From: Sprecher, Nurit (NSN - IL/Hod HaSharon) =20 To: ext Fatai Zhang =20 Cc: Clemens, Rainer (NSN - DE/Munich) ; CCAMP ; Soininen, Jonne (NSN - FI/Espoo) ; Li Dan ; han jianrui ; lihan@chinamobile.com=20 Sent: Friday, October 23, 2009 9:40 PM Subject: RE: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt Hi Fatai, Thanks for your response. =20 Referring to a document which is not a standard is problematic and even confusing. I am not sure that all the IETF colleagues could realize that a supplement document in the ITU-T is not considered as a standard. As you agreed below, G.Sup43 is NOT a standard.=20 I believe it is NOT in the scope of CCAMP to define the dataplane behavior of ODU switching...we can define a control plane for a standard dataplane and refer to the dataplane standard behavior.=20 Once (and if) it is defined as a standard behavior in the ITU-T, there will be room to specify an extension for GMPLS (if necessary) to support it.=20 =20 Also, I would like to note that it was NEVER discussed in SG1/Q11 to allow other mappings than ODU2e into ODU3e. It was even explicitly stated that no other mapping should be described in G.Sup43. The WP3 report from the plenary in December 2008 states that :"After discussion, the agreement was reached to document two versions of ODU3e, one based on the Huawei and CMCC proposal (using the eventual GMP chosen for ODU4) and the other based on the NTT and Japan proposals. Agreement was reached to only document the mapping of four 10GBASE-R clients into each of these two versions of ODU3e in an updated G.Sup43.". =20 Nevertheless, even if specified in G.Sup43, we need to keep in mind that this is NOT a standard and we cannot refer to it as such. =20 Best regards, Nurit =20 =09 ________________________________ From: ext Fatai Zhang [mailto:zhangfatai@huawei.com]=20 Sent: Friday, October 23, 2009 9:40 AM To: Sprecher, Nurit (NSN - IL/Hod HaSharon) Cc: Clemens, Rainer (NSN - DE/Munich); CCAMP; Soininen, Jonne (NSN - FI/Espoo); Li Dan; han jianrui; lihan@chinamobile.com Subject: Re: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt =20 Hi Nurit, =20 Thanks for your comments. =20 Please see below for in-line responses. =20 =20 =20 =20 =20 Thanks =20 Fatai =20 Advanced Technology Department Wireline Networking Business Unit Huawei Technologies Co., LTD. Huawei Base, Bantian, Longgang, Shenzhen 518129 P.R.China Tel: +86-755-28972912 Fax: +86-755-28972935 ----- Original Message -----=20 From: Sprecher, Nurit (NSN - IL/Hod HaSharon) =20 To: zhangfatai@huawei.com ; danli@huawei.com ; hanjianrui@huawei.com ; lihan@chinamobile.com=20 Cc: Clemens, Rainer (NSN - DE/Munich) ; ccamp@ietf.org ; Soininen, Jonne (NSN - FI/Espoo) =20 Sent: Thursday, October 22, 2009 1:42 AM Subject: RE: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt =20 =20 Dear authors,=20 =20 Thanks for submitting your document on "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks". =20 We have reviewed the document and we are a little bit concerned to find out that some significant items described in the document are not aligned with what is defined in G.709. =20 Especially the mappings into ODU3e1 and ODU3e2 are only defined in G.Sup43 which is not a standard.=20 In addition G.Sup43 does not define mappings of ODU0, ODU1, ODU2 and ODUflex into ODU3e2. The only mappings that are defined in G.Sup43 are 4x ODU2e. =20 [Fatai] Yes, you are right and we also indicated in this draft that ODU3e1 and ODU3e2 are defined in G.Sup43. You know G.Sup is not standard currently,so I think we have some options for this. (1)add a note to explain that ODU3e1 and ODU3e2 are still non-standard explicitly (2) change the title of this draft to "Framework for GMPLS and PCE Control of Optical Transport Networks" (3) move ODU3e2 to an appendix. =20 In addition, I think we can cover ODU3e1 and ODU3e2 in this draft at this stage (i.e., individual draft), because they are being developed in ITU-T and may be accepted by ITU-T some day. I will reflect this in the next version.=20 =20 =20 We are afraid that this is not inline with the view of the majority of participants in SG15/Q11. =20 [Fatai] I don't know whether it is true or not. But I think we can hear the opinions from SG15/Q11. =20 Except of the extensions that are already described in two draft (draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn, draft-zhang-ccamp-gmpls-evolving-g709), all other content of section 3, 4 is copied from ITU standards. Would not it be better to just refer to the ITU-T document? =20 [Fatai] In Section 3, some part of information is from G.709 and G.872 and we reference this recommendations explicitly. We just try to give a brief overview of OTN to CCAMP experts from the perspective of Control Plane and make everyone quickly understand why we need more considerations on OTN control. I think it is really tough for everyone to go through G.709, G.872 and other recommendations detailedly. As for Section 4, I don't know why you said that it is copied from ITU standards. In Section 4, it describes the connection management model for OTN networks, which is based on our understanding and some discussions in ITU-T Q12.=20 =20 Best regards, Nurit =20 =20 =20 >=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org=20 > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of ext=20 > Internet-Drafts@ietf.org > Sent: Friday, October 16, 2009 11:45 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Framework for GMPLS and PCE Control=20 > of G.709 Optical Transport Networks > Author(s) : F. Zhang, et al. > Filename : draft-zhang-ccamp-gmpls-g709-framework-00.txt > Pages : 27 > Date : 2009-10-16 >=20 > This document provides a framework for applying Generalized Mulit- > Protocol Label Switching (GMPLS) and the Path Computation Element=20 > (PCE) architecture to the control of G.709 Optical Transport Networks=20 > (OTN) as specified in the ITU-T G.709 recommendation, including the=20 > enhanced functionality in the recently consented revision.=20 >=20 > =20 > =20 > =20 > zhang >=20 >=20 >=20 >=20 >=20 > Expires April 2010 >=20 >=20 >=20 >=20 >=20 > [page 1]=20 >=20 > draft-zhang-ccamp-gmpls-g709-framework-00.txt >=20 >=20 >=20 > October 2009=20 > =20 >=20 > Conventions used in this document=20 >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20 > document are to be interpreted as described in [RFC2119]. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zhang-ccamp-gmpls-g7 > 09-framework-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 ------_=_NextPart_001_01CA57EC.C91350A7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Fatai,
I=20 think that in the IETF we should only put things in the normative part of the = document=20 that is also normative in ITU-T, i.e. in this case only what is written = in the=20 normative sections in G.709.
Everything in G.Sup43 can go into an = appendix, i.e.=20 mappings of 4x ODU2e into ODU3e1/2 and even OTU2e line signals. We = should also=20 mention what is the actual status of the G.sup43. =
Other things that are being discussed in = ITU-T and=20 are not approved should stay completely out.
Best regards,
Nurit

From: ext Fatai Zhang=20 [mailto:zhangfatai@huawei.com]
Sent: Monday, October 26, 2009 = 2:56=20 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: = Clemens,=20 Rainer (NSN - DE/Munich); CCAMP; Soininen, Jonne (NSN - FI/Espoo); Li = Dan; han=20 jianrui; lihan@chinamobile.com
Subject: Re: I-D=20 Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

=
Hi Nurit,
 
Thanks for your further comments.
 
We think we can move the content = of G.sup43=20 to an appendix ( just for information), and explain that this part = of=20 information is not consented by ITU-T SG15.
 
We can also remove this appendix later, if this = draft is=20 ready to be RFC and the content of G.sup43 is still not consented (i.e., = non-standard).
 
Is it OK for you? :-)~~~~, If Yes, we will = reflect it in=20 the next version.
 
 
 
Thanks
 
Fatai
 
Advanced Technology Department
Wireline = Networking=20 Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian,=20 Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax:=20 +86-755-28972935
----- Original Message ----- =
Cc: Clemens, Rainer (NSN - = DE/Munich) ;=20 CCAMP ; = Soininen,=20 Jonne (NSN - FI/Espoo) ; Li Dan ; han jianrui ; lihan@chinamobile.com
Sent: Friday, October = 23, 2009 9:40 PM
Subject: RE: I-D=20 Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

Hi=20 Fatai,

Thanks for = your=20 response.

 

Referring = to a=20 document which is not a standard is problematic and even confusing. I = am not=20 sure that all the IETF colleagues could realize that a supplement = document in=20 the ITU-T is not considered as a standard. As you agreed below, = G.Sup43 is=20 NOT a standard.

I believe = it is NOT=20 in the scope of CCAMP to define the dataplane behavior of ODU = switching…we can=20 define a control plane for a standard dataplane and refer to the = dataplane=20 standard behavior.

Once (and = if) it is=20 defined as a standard behavior in the ITU-T, there will be room to = specify an=20 extension for GMPLS (if necessary) to support it.=20

 

Also, I = would like=20 to note that it was NEVER discussed in SG1/Q11 to allow other mappings = than=20 ODU2e into ODU3e. It was even explicitly=20 stated that no other mapping should be described in = G.Sup43. The WP3 report from the plenary in December 2008 states that = :"After=20 discussion, the agreement was reached to document two versions of = ODU3e, one=20 based on the Huawei and CMCC proposal (using the eventual GMP chosen = for ODU4)=20 and the other based on the NTT and Japan = proposals.  Agreement=20 was reached to only document = the mapping of=20 four 10GBASE-R clients into each of these two versions = of ODU3e in=20 an updated G.Sup43.".

 

Nevertheless, even if=20 specified in G.Sup43, we need to keep in mind that this is NOT a = standard and=20 we cannot refer to it as such.

 

Best=20 regards,

Nurit

 

From: ext=20 Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Friday, October 23, 2009 = 9:40=20 AM
To: Sprecher, = Nurit (NSN -=20 IL/Hod HaSharon)
Cc: Clemens,=20 Rainer (NSN - DE/Munich); CCAMP; Soininen, Jonne (NSN - FI/Espoo); Li = Dan; han=20 jianrui; lihan@chinamobile.com
Subject: Re: I-D=20 = Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

 

Hi=20 Nurit,

 

Thanks for your=20 comments.

 

Please see below=20 = for in-line responses.

=

 

 

 

 

 

Thanks

 

Fatai
 
Advanced=20 Technology Department
Wireline Networking Business Unit
Huawei=20 Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen = 518129=20 P.R.China
Tel: +86-755-28972912
Fax:=20 +86-755-28972935

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

From: Sprecher,=20 Nurit (NSN - IL/Hod HaSharon) =

To: zhangfatai@huawei.com ; danli@huawei.com ;=20 hanjianrui@huawei.com ; lihan@chinamobile.com=20

Cc: Clemens,=20 Rainer (NSN - DE/Munich) ; ccamp@ietf.org ; Soininen,=20 Jonne (NSN - FI/Espoo)

Sent:=20 Thursday, October 22, 2009 1:42 = AM

Subject: RE:=20 I-D=20 = Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt

 

 

Dear authors, =

 

Thanks for submitting your document on = "Framework=20 for GMPLS and PCE Control of G.709 Optical Transport=20 Networks".

 

We have reviewed the document and we are a = little=20 bit concerned to find out that some significant items described in = the=20 document are not aligned with what is defined in=20 G.709.

 

Especially the = mappings=20 into ODU3e1 and ODU3e2 are only defined in G.Sup43 which is not a = standard.=20

In addition = G.Sup43 does=20 not define mappings of ODU0, ODU1, ODU2 and ODUflex into = ODU3e2. The=20 only mappings that are defined in G.Sup43 are 4x=20 ODU2e.

 

[Fatai] = Yes, you=20 are right and we also indicated in this draft that ODU3e1 and ODU3e2 = are=20 defined in G.Sup43. = You know=20 G.Sup is not standard currently,so I think we have some options for = this.=20 (1)add a note to explain that ODU3e1 and ODU3e2 are still = non-standard=20 explicitly (2) change the title of this draft to "Framework for = GMPLS and=20 PCE Control of Optical Transport Networks" (3) move = ODU3e2  to an=20 appendix. 

In = addition, I=20 think we can cover ODU3e1 and ODU3e2 in this draft at this stage = (i.e.,=20 individual draft), because they are being developed in ITU-T and may = be=20 accepted by ITU-T some day.

I will = reflect this=20 in the next version.

 

 

We are afraid that this is not inline with = the view=20 of the majority of participants in = SG15/Q11.

 

[Fatai] I = don't=20 know whether it is true or not. But I think we can hear the opinions = from=20 SG15/Q11.

 

Except of the extensions that are already = described=20 in two draft (draft-ceccarellifuxh-ccamp-gmpls-ext-for-evol-otn,=20 draft-zhang-ccamp-gmpls-evolving-g709), all other content of section = 3, 4 is=20 copied from ITU standards. Would not it be better to just refer to = the ITU-T=20 document?

 

[Fatai] = In Section=20 3, some part of information is from G.709 and G.872 and we = reference=20 this recommendations explicitly. We just try to give a brief = overview of OTN=20 to CCAMP experts from the perspective of Control Plane and make = everyone=20 quickly understand why we need more considerations on OTN control. I = think=20 it is really tough for everyone to go through G.709, G.872 and other = recommendations detailedly. As for  Section 4, I don't = know why=20 you said that it is copied from ITU standards.  In Section 4,=20 it describes the connection management model for OTN=20 networks, which is based on our understanding and some = discussions in=20 ITU-T Q12. 

 

Best regards,

Nurit

 

 

 

>

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

> From: i-d-announce-bounces@ietf.org =

> = [mailto:i-d-announce-bounces@ietf.org] On=20 Behalf Of ext

>=20 Internet-Drafts@ietf.org

> Sent: Friday, October 16, 2009 = 11:45=20 AM

> To:=20 i-d-announce@ietf.org

> Subject: I-D=20 Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt=20

>

> A New Internet-Draft is available = from the=20 on-line

> Internet-Drafts=20 directories.

>

>    =20 Title           = :=20 Framework for GMPLS and PCE Control

> of G.709 Optical Transport=20 Networks

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

>    =20 Filename        :=20 = draft-zhang-ccamp-gmpls-g709-framework-00.txt

>    =20 Pages           = :=20 27

>    =20 = Date            : = 2009-10-16

>

> This document provides a framework = for=20 applying Generalized Mulit-

> Protocol Label Switching (GMPLS) = and the Path=20 Computation Element

> (PCE) architecture to the control = of G.709=20 Optical Transport Networks

> (OTN) as specified in the ITU-T = G.709=20 recommendation, including the

> enhanced functionality in the = recently=20 consented revision.

>

> 

> 

> 

> zhang

>

>

>

>

>

>   Expires April=20 2010

>

>

>

>

>

>   [page 1]=20

>

>=20 = draft-zhang-ccamp-gmpls-g709-framework-00.txt

>

>

>

>   October 2009=20

> 

>

> Conventions used in this document=20

>

> The key words "MUST", "MUST NOT", = "REQUIRED",=20 "SHALL", "SHALL NOT",

> "SHOULD", "SHOULD NOT", = "RECOMMENDED", "MAY",=20 and "OPTIONAL" in this

> document are to be interpreted as = described=20 in [RFC2119].

>

> A URL for this Internet-Draft=20 is:

>=20 = http://www.ietf.org/internet-drafts/draft-zhang-ccamp-gmpls-g7=

>=20 09-framework-00.txt

>

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

>=20 ftp://ftp.ietf.org/internet-drafts/

>

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

> implementation to automatically = retrieve the=20 ASCII version of the

> = Internet-Draft.

>=20 =

------_=_NextPart_001_01CA57EC.C91350A7-- From lmartini@cisco.com Wed Oct 28 15:32:24 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BF933A6989; Wed, 28 Oct 2009 15:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9L68KBwqTx7F; Wed, 28 Oct 2009 15:32:23 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [67.41.208.110]) by core3.amsl.com (Postfix) with ESMTP id 7890A3A6809; Wed, 28 Oct 2009 15:32:23 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id n9SMWZgX012840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 16:32:35 -0600 (MDT) Message-ID: <4AE8C683.5010409@cisco.com> Date: Wed, 28 Oct 2009 16:32:35 -0600 From: Luca Martini User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Loa Andersson References: <4AE60B70.6090603@pi.nu> In-Reply-To: <4AE60B70.6090603@pi.nu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 209.245.27.1 Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, "mpls-tp@ietf.org" Subject: Re: [CCAMP] [mpls-tp] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 22:32:24 -0000 Yes/Support Luca Loa Andersson wrote: > All, > > this is to start a two week poll in making > > draft-swallow-mpls-tp-identifiers-02.txt > > an MPLS working group document. > > Send a mail to the mpls-tp@ietf.org mailing list, indicating > "yes/support" or "no/do not support". > > Comments on the content of the draft should be sent to the same > mailing list with a different subject line. > > The poll ends Sun Nov 8. > > /Loa > > MPLS WG co-chair > > From fu.xihua@zte.com.cn Wed Oct 28 23:58:31 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A528F3A685A; Wed, 28 Oct 2009 23:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.435 X-Spam-Level: X-Spam-Status: No, score=-96.435 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_92=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlVeZYT-WarM; Wed, 28 Oct 2009 23:58:29 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id AC6783A6973; Wed, 28 Oct 2009 23:58:28 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111641461793122; Thu, 29 Oct 2009 14:31:40 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 14630.6649415828; Thu, 29 Oct 2009 14:46:20 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n9T6sxGZ032548; Thu, 29 Oct 2009 14:55:08 +0800 (CST) (envelope-from fu.xihua@zte.com.cn) In-Reply-To: <077E41CFFD002C4CAB7DFA4386A532640173CAF7@DEMUEXC014.nsn-intra.net> To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Thu, 29 Oct 2009 14:55:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-10-29 14:55:01, Serialize complete at 2009-10-29 14:55:01 Content-Type: multipart/alternative; boundary="=_alternative 0025FA114825765E_=" X-MAIL: mse1.zte.com.cn n9T6sxGZ032548 Cc: "Soininen, Jonne \(NSN - FI/Espoo\)" , CCAMP , "Clemens, Rainer \(NSN - DE/Munich\)" , ccamp-bounces@ietf.org Subject: Re: [CCAMP] I-D Action:draft-zhang-ccamp-gmpls-g709-framework-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 06:58:31 -0000 This is a multipart message in MIME format. --=_alternative 0025FA114825765E_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTnVyaXQsDQoNCkkgYWdyZWUgd2l0aCB5b3UuIEFsbCBjb250ZW50IG9mIHNlY3Rpb24gMyBp biB0aGlzIGRyYWZ0ICBpcyBmcm9tIEcuNzA5LiANCkluIG9yZGVyIHRvIGJlIGNvbnNpc3RlbnQg d2l0aCBHLjcwOSAoZS5nLiwgT0RVMyBzaG91ZGwgb2NjdXB5IDMxIG9mIHRoZSANCjgwIFRTIGlu IE9EVTQgYmFzZWQgb24gdGhlIGN1cnJlbnQgRy43MDkgQW1kMyksIEkgc3VnZ2VzdCB0aGUgd2hv bGUgDQpjb250ZW50IGFib3V0IEcuNzA5IGJlIGp1c3QgcmVmZXJlZCB0byBHLjcwOSBvciBtb3Zl IHRvIHRoZSBBcHBlbmRpeC4NCg0KQmVzdCBSZWdhcmRzLA0KWGlodWEgRnUNClpURSBDb3Jwb3Jh dGlvbg0KDQoNCg0KDQoiU3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pIiA8 bnVyaXQuc3ByZWNoZXJAbnNuLmNvbT4gDQq3orz+yMs6ICBjY2FtcC1ib3VuY2VzQGlldGYub3Jn DQoyMDA5LTEwLTI5IMnPzucgMTI6MzYNCg0KytW8/sjLDQoiZXh0IEZhdGFpIFpoYW5nIiA8emhh bmdmYXRhaUBodWF3ZWkuY29tPg0Ks63LzQ0KIkNsZW1lbnMsIFJhaW5lciBcKE5TTiAtIERFL011 bmljaFwpIiA8cmFpbmVyLmNsZW1lbnNAbnNuLmNvbT4sICJTb2luaW5lbiwgDQpKb25uZSBcKE5T TiAtIEZJL0VzcG9vXCkiIDxqb25uZS5zb2luaW5lbkBuc24uY29tPiwgQ0NBTVAgPGNjYW1wQGll dGYub3JnPg0K1vfM4g0KUmU6IFtDQ0FNUF0gSS1EIEFjdGlvbjpkcmFmdC16aGFuZy1jY2FtcC1n bXBscy1nNzA5LWZyYW1ld29yay0wMC50eHQNCg0KDQoNCg0KDQoNCkhpIEZhdGFpLA0KSSB0aGlu ayB0aGF0IGluIHRoZSBJRVRGIHdlIHNob3VsZCBvbmx5IHB1dCB0aGluZ3MgaW4gdGhlIG5vcm1h dGl2ZSBwYXJ0IA0Kb2YgdGhlIGRvY3VtZW50IHRoYXQgaXMgYWxzbyBub3JtYXRpdmUgaW4gSVRV LVQsIGkuZS4gaW4gdGhpcyBjYXNlIG9ubHkgDQp3aGF0IGlzIHdyaXR0ZW4gaW4gdGhlIG5vcm1h dGl2ZSBzZWN0aW9ucyBpbiBHLjcwOS4gDQpFdmVyeXRoaW5nIGluIEcuU3VwNDMgY2FuIGdvIGlu dG8gYW4gYXBwZW5kaXgsIGkuZS4gbWFwcGluZ3Mgb2YgNHggT0RVMmUgDQppbnRvIE9EVTNlMS8y IGFuZCBldmVuIE9UVTJlIGxpbmUgc2lnbmFscy4gV2Ugc2hvdWxkIGFsc28gbWVudGlvbiB3aGF0 IGlzIA0KdGhlIGFjdHVhbCBzdGF0dXMgb2YgdGhlIEcuc3VwNDMuIA0KT3RoZXIgdGhpbmdzIHRo YXQgYXJlIGJlaW5nIGRpc2N1c3NlZCBpbiBJVFUtVCBhbmQgYXJlIG5vdCBhcHByb3ZlZCBzaG91 bGQgDQpzdGF5IGNvbXBsZXRlbHkgb3V0Lg0KQmVzdCByZWdhcmRzLA0KTnVyaXQgDQoNCkZyb206 IGV4dCBGYXRhaSBaaGFuZyBbbWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbV0gDQpTZW50OiBN b25kYXksIE9jdG9iZXIgMjYsIDIwMDkgMjo1NiBQTQ0KVG86IFNwcmVjaGVyLCBOdXJpdCAoTlNO IC0gSUwvSG9kIEhhU2hhcm9uKQ0KQ2M6IENsZW1lbnMsIFJhaW5lciAoTlNOIC0gREUvTXVuaWNo KTsgQ0NBTVA7IFNvaW5pbmVuLCBKb25uZSAoTlNOIC0gDQpGSS9Fc3Bvbyk7IExpIERhbjsgaGFu IGppYW5ydWk7IGxpaGFuQGNoaW5hbW9iaWxlLmNvbQ0KU3ViamVjdDogUmU6IEktRCBBY3Rpb246 ZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDAudHh0DQoNCkhpIE51cml0 LA0KIA0KVGhhbmtzIGZvciB5b3VyIGZ1cnRoZXIgY29tbWVudHMuDQogDQpXZSB0aGluayB3ZSBj YW4gbW92ZSB0aGUgY29udGVudCBvZiBHLnN1cDQzIHRvIGFuIGFwcGVuZGl4ICgganVzdCBmb3Ig DQppbmZvcm1hdGlvbiksIGFuZCBleHBsYWluIHRoYXQgdGhpcyBwYXJ0IG9mIGluZm9ybWF0aW9u IGlzIG5vdCBjb25zZW50ZWQgDQpieSBJVFUtVCBTRzE1Lg0KIA0KV2UgY2FuIGFsc28gcmVtb3Zl IHRoaXMgYXBwZW5kaXggbGF0ZXIsIGlmIHRoaXMgZHJhZnQgaXMgcmVhZHkgdG8gYmUgUkZDIA0K YW5kIHRoZSBjb250ZW50IG9mIEcuc3VwNDMgaXMgc3RpbGwgbm90IGNvbnNlbnRlZCAoaS5lLiwg bm9uLXN0YW5kYXJkKS4NCiANCklzIGl0IE9LIGZvciB5b3U/IDotKX5+fn4sIElmIFllcywgd2Ug d2lsbCByZWZsZWN0IGl0IGluIHRoZSBuZXh0IHZlcnNpb24uDQogDQogDQogDQpUaGFua3MNCiAN CkZhdGFpDQogDQpBZHZhbmNlZCBUZWNobm9sb2d5IERlcGFydG1lbnQNCldpcmVsaW5lIE5ldHdv cmtpbmcgQnVzaW5lc3MgVW5pdA0KSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIExURC4NCkh1YXdl aSBCYXNlLCBCYW50aWFuLCBMb25nZ2FuZywNClNoZW56aGVuIDUxODEyOSBQLlIuQ2hpbmENClRl bDogKzg2LTc1NS0yODk3MjkxMg0KRmF4OiArODYtNzU1LTI4OTcyOTM1DQotLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogU3ByZWNoZXIsIE51cml0IChOU04gLSBJTC9Ib2QgSGFT aGFyb24pIA0KVG86IGV4dCBGYXRhaSBaaGFuZyANCkNjOiBDbGVtZW5zLCBSYWluZXIgKE5TTiAt IERFL011bmljaCkgOyBDQ0FNUCA7IFNvaW5pbmVuLCBKb25uZSAoTlNOIC0gDQpGSS9Fc3Bvbykg OyBMaSBEYW4gOyBoYW4gamlhbnJ1aSA7IGxpaGFuQGNoaW5hbW9iaWxlLmNvbSANClNlbnQ6IEZy aWRheSwgT2N0b2JlciAyMywgMjAwOSA5OjQwIFBNDQpTdWJqZWN0OiBSRTogSS1EIEFjdGlvbjpk cmFmdC16aGFuZy1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0wMC50eHQNCg0KSGkgRmF0YWks DQpUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UuDQogDQpSZWZlcnJpbmcgdG8gYSBkb2N1bWVudCB3 aGljaCBpcyBub3QgYSBzdGFuZGFyZCBpcyBwcm9ibGVtYXRpYyBhbmQgZXZlbiANCmNvbmZ1c2lu Zy4gSSBhbSBub3Qgc3VyZSB0aGF0IGFsbCB0aGUgSUVURiBjb2xsZWFndWVzIGNvdWxkIHJlYWxp emUgdGhhdCBhIA0Kc3VwcGxlbWVudCBkb2N1bWVudCBpbiB0aGUgSVRVLVQgaXMgbm90IGNvbnNp ZGVyZWQgYXMgYSBzdGFuZGFyZC4gQXMgeW91IA0KYWdyZWVkIGJlbG93LCBHLlN1cDQzIGlzIE5P VCBhIHN0YW5kYXJkLiANCkkgYmVsaWV2ZSBpdCBpcyBOT1QgaW4gdGhlIHNjb3BlIG9mIENDQU1Q IHRvIGRlZmluZSB0aGUgZGF0YXBsYW5lIGJlaGF2aW9yIA0Kb2YgT0RVIHN3aXRjaGluZ6Gtd2Ug Y2FuIGRlZmluZSBhIGNvbnRyb2wgcGxhbmUgZm9yIGEgc3RhbmRhcmQgZGF0YXBsYW5lIA0KYW5k IHJlZmVyIHRvIHRoZSBkYXRhcGxhbmUgc3RhbmRhcmQgYmVoYXZpb3IuIA0KT25jZSAoYW5kIGlm KSBpdCBpcyBkZWZpbmVkIGFzIGEgc3RhbmRhcmQgYmVoYXZpb3IgaW4gdGhlIElUVS1ULCB0aGVy ZSANCndpbGwgYmUgcm9vbSB0byBzcGVjaWZ5IGFuIGV4dGVuc2lvbiBmb3IgR01QTFMgKGlmIG5l Y2Vzc2FyeSkgdG8gc3VwcG9ydCANCml0LiANCiANCkFsc28sIEkgd291bGQgbGlrZSB0byBub3Rl IHRoYXQgaXQgd2FzIE5FVkVSIGRpc2N1c3NlZCBpbiBTRzEvUTExIHRvIGFsbG93IA0Kb3RoZXIg bWFwcGluZ3MgdGhhbiBPRFUyZSBpbnRvIE9EVTNlLiBJdCB3YXMgZXZlbiBleHBsaWNpdGx5IHN0 YXRlZCB0aGF0IA0Kbm8gb3RoZXIgbWFwcGluZyBzaG91bGQgYmUgZGVzY3JpYmVkIGluIEcuU3Vw NDMuIFRoZSBXUDMgcmVwb3J0IGZyb20gdGhlIA0KcGxlbmFyeSBpbiBEZWNlbWJlciAyMDA4IHN0 YXRlcyB0aGF0IDoiQWZ0ZXIgZGlzY3Vzc2lvbiwgdGhlIGFncmVlbWVudCB3YXMgDQpyZWFjaGVk IHRvIGRvY3VtZW50IHR3byB2ZXJzaW9ucyBvZiBPRFUzZSwgb25lIGJhc2VkIG9uIHRoZSBIdWF3 ZWkgYW5kIA0KQ01DQyBwcm9wb3NhbCAodXNpbmcgdGhlIGV2ZW50dWFsIEdNUCBjaG9zZW4gZm9y IE9EVTQpIGFuZCB0aGUgb3RoZXIgYmFzZWQgDQpvbiB0aGUgTlRUIGFuZCBKYXBhbiBwcm9wb3Nh bHMuICBBZ3JlZW1lbnQgd2FzIHJlYWNoZWQgdG8gb25seSBkb2N1bWVudCANCnRoZSBtYXBwaW5n IG9mIGZvdXIgMTBHQkFTRS1SIGNsaWVudHMgaW50byBlYWNoIG9mIHRoZXNlIHR3byB2ZXJzaW9u cyBvZiANCk9EVTNlIGluIGFuIHVwZGF0ZWQgRy5TdXA0My4iLg0KIA0KTmV2ZXJ0aGVsZXNzLCBl dmVuIGlmIHNwZWNpZmllZCBpbiBHLlN1cDQzLCB3ZSBuZWVkIHRvIGtlZXAgaW4gbWluZCB0aGF0 IA0KdGhpcyBpcyBOT1QgYSBzdGFuZGFyZCBhbmQgd2UgY2Fubm90IHJlZmVyIHRvIGl0IGFzIHN1 Y2guDQogDQpCZXN0IHJlZ2FyZHMsDQpOdXJpdA0KIA0KDQpGcm9tOiBleHQgRmF0YWkgWmhhbmcg W21haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb21dIA0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDIz LCAyMDA5IDk6NDAgQU0NClRvOiBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJv bikNCkNjOiBDbGVtZW5zLCBSYWluZXIgKE5TTiAtIERFL011bmljaCk7IENDQU1QOyBTb2luaW5l biwgSm9ubmUgKE5TTiAtIA0KRkkvRXNwb28pOyBMaSBEYW47IGhhbiBqaWFucnVpOyBsaWhhbkBj aGluYW1vYmlsZS5jb20NClN1YmplY3Q6IFJlOiBJLUQgQWN0aW9uOmRyYWZ0LXpoYW5nLWNjYW1w LWdtcGxzLWc3MDktZnJhbWV3b3JrLTAwLnR4dA0KIA0KSGkgTnVyaXQsDQogDQpUaGFua3MgZm9y IHlvdXIgY29tbWVudHMuDQogDQpQbGVhc2Ugc2VlIGJlbG93IGZvciBpbi1saW5lIHJlc3BvbnNl cy4NCiANCiANCiANCiANCiANClRoYW5rcw0KIA0KRmF0YWkNCiANCkFkdmFuY2VkIFRlY2hub2xv Z3kgRGVwYXJ0bWVudA0KV2lyZWxpbmUgTmV0d29ya2luZyBCdXNpbmVzcyBVbml0DQpIdWF3ZWkg VGVjaG5vbG9naWVzIENvLiwgTFRELg0KSHVhd2VpIEJhc2UsIEJhbnRpYW4sIExvbmdnYW5nLA0K U2hlbnpoZW4gNTE4MTI5IFAuUi5DaGluYQ0KVGVsOiArODYtNzU1LTI4OTcyOTEyDQpGYXg6ICs4 Ni03NTUtMjg5NzI5MzUNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiBTcHJl Y2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbikgDQpUbzogemhhbmdmYXRhaUBodWF3 ZWkuY29tIDsgZGFubGlAaHVhd2VpLmNvbSA7IGhhbmppYW5ydWlAaHVhd2VpLmNvbSA7IA0KbGlo YW5AY2hpbmFtb2JpbGUuY29tIA0KQ2M6IENsZW1lbnMsIFJhaW5lciAoTlNOIC0gREUvTXVuaWNo KSA7IGNjYW1wQGlldGYub3JnIDsgU29pbmluZW4sIEpvbm5lIA0KKE5TTiAtIEZJL0VzcG9vKSAN ClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDIyLCAyMDA5IDE6NDIgQU0NClN1YmplY3Q6IFJFOiBJ LUQgQWN0aW9uOmRyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAwLnR4dA0K IA0KIA0KRGVhciBhdXRob3JzLCANCiANClRoYW5rcyBmb3Igc3VibWl0dGluZyB5b3VyIGRvY3Vt ZW50IG9uICJGcmFtZXdvcmsgZm9yIEdNUExTIGFuZCBQQ0UgDQpDb250cm9sIG9mIEcuNzA5IE9w dGljYWwgVHJhbnNwb3J0IE5ldHdvcmtzIi4NCiANCldlIGhhdmUgcmV2aWV3ZWQgdGhlIGRvY3Vt ZW50IGFuZCB3ZSBhcmUgYSBsaXR0bGUgYml0IGNvbmNlcm5lZCB0byBmaW5kIA0Kb3V0IHRoYXQg c29tZSBzaWduaWZpY2FudCBpdGVtcyBkZXNjcmliZWQgaW4gdGhlIGRvY3VtZW50IGFyZSBub3Qg YWxpZ25lZCANCndpdGggd2hhdCBpcyBkZWZpbmVkIGluIEcuNzA5Lg0KIA0KRXNwZWNpYWxseSB0 aGUgbWFwcGluZ3MgaW50byBPRFUzZTEgYW5kIE9EVTNlMiBhcmUgb25seSBkZWZpbmVkIGluIEcu U3VwNDMgDQp3aGljaCBpcyBub3QgYSBzdGFuZGFyZC4gDQpJbiBhZGRpdGlvbiBHLlN1cDQzIGRv ZXMgbm90IGRlZmluZSBtYXBwaW5ncyBvZiBPRFUwLCBPRFUxLCBPRFUyIGFuZCANCk9EVWZsZXgg aW50byBPRFUzZTIuIFRoZSBvbmx5IG1hcHBpbmdzIHRoYXQgYXJlIGRlZmluZWQgaW4gRy5TdXA0 MyBhcmUgNHggDQpPRFUyZS4NCiANCltGYXRhaV0gWWVzLCB5b3UgYXJlIHJpZ2h0IGFuZCB3ZSBh bHNvIGluZGljYXRlZCBpbiB0aGlzIGRyYWZ0IHRoYXQgT0RVM2UxIA0KYW5kIE9EVTNlMiBhcmUg ZGVmaW5lZCBpbiBHLlN1cDQzLiBZb3Uga25vdyBHLlN1cCBpcyBub3Qgc3RhbmRhcmQgDQpjdXJy ZW50bHksc28gSSB0aGluayB3ZSBoYXZlIHNvbWUgb3B0aW9ucyBmb3IgdGhpcy4gKDEpYWRkIGEg bm90ZSB0byANCmV4cGxhaW4gdGhhdCBPRFUzZTEgYW5kIE9EVTNlMiBhcmUgc3RpbGwgbm9uLXN0 YW5kYXJkIGV4cGxpY2l0bHkgKDIpIA0KY2hhbmdlIHRoZSB0aXRsZSBvZiB0aGlzIGRyYWZ0IHRv ICJGcmFtZXdvcmsgZm9yIEdNUExTIGFuZCBQQ0UgQ29udHJvbCBvZiANCk9wdGljYWwgVHJhbnNw b3J0IE5ldHdvcmtzIiAoMykgbW92ZSBPRFUzZTIgIHRvIGFuIGFwcGVuZGl4LiANCkluIGFkZGl0 aW9uLCBJIHRoaW5rIHdlIGNhbiBjb3ZlciBPRFUzZTEgYW5kIE9EVTNlMiBpbiB0aGlzIGRyYWZ0 IGF0IHRoaXMgDQpzdGFnZSAoaS5lLiwgaW5kaXZpZHVhbCBkcmFmdCksIGJlY2F1c2UgdGhleSBh cmUgYmVpbmcgZGV2ZWxvcGVkIGluIElUVS1UIA0KYW5kIG1heSBiZSBhY2NlcHRlZCBieSBJVFUt VCBzb21lIGRheS4NCkkgd2lsbCByZWZsZWN0IHRoaXMgaW4gdGhlIG5leHQgdmVyc2lvbi4gDQog DQogDQpXZSBhcmUgYWZyYWlkIHRoYXQgdGhpcyBpcyBub3QgaW5saW5lIHdpdGggdGhlIHZpZXcg b2YgdGhlIG1ham9yaXR5IG9mIA0KcGFydGljaXBhbnRzIGluIFNHMTUvUTExLg0KIA0KW0ZhdGFp XSBJIGRvbid0IGtub3cgd2hldGhlciBpdCBpcyB0cnVlIG9yIG5vdC4gQnV0IEkgdGhpbmsgd2Ug Y2FuIGhlYXIgDQp0aGUgb3BpbmlvbnMgZnJvbSBTRzE1L1ExMS4NCiANCkV4Y2VwdCBvZiB0aGUg ZXh0ZW5zaW9ucyB0aGF0IGFyZSBhbHJlYWR5IGRlc2NyaWJlZCBpbiB0d28gZHJhZnQgDQooZHJh ZnQtY2VjY2FyZWxsaWZ1eGgtY2NhbXAtZ21wbHMtZXh0LWZvci1ldm9sLW90biwgDQpkcmFmdC16 aGFuZy1jY2FtcC1nbXBscy1ldm9sdmluZy1nNzA5KSwgYWxsIG90aGVyIGNvbnRlbnQgb2Ygc2Vj dGlvbiAzLCA0IA0KaXMgY29waWVkIGZyb20gSVRVIHN0YW5kYXJkcy4gV291bGQgbm90IGl0IGJl IGJldHRlciB0byBqdXN0IHJlZmVyIHRvIHRoZSANCklUVS1UIGRvY3VtZW50Pw0KIA0KW0ZhdGFp XSBJbiBTZWN0aW9uIDMsIHNvbWUgcGFydCBvZiBpbmZvcm1hdGlvbiBpcyBmcm9tIEcuNzA5IGFu ZCBHLjg3MiBhbmQgDQp3ZSByZWZlcmVuY2UgdGhpcyByZWNvbW1lbmRhdGlvbnMgZXhwbGljaXRs eS4gV2UganVzdCB0cnkgdG8gZ2l2ZSBhIGJyaWVmIA0Kb3ZlcnZpZXcgb2YgT1ROIHRvIENDQU1Q IGV4cGVydHMgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgQ29udHJvbCBQbGFuZSBhbmQgDQptYWtl IGV2ZXJ5b25lIHF1aWNrbHkgdW5kZXJzdGFuZCB3aHkgd2UgbmVlZCBtb3JlIGNvbnNpZGVyYXRp b25zIG9uIE9UTiANCmNvbnRyb2wuIEkgdGhpbmsgaXQgaXMgcmVhbGx5IHRvdWdoIGZvciBldmVy eW9uZSB0byBnbyB0aHJvdWdoIEcuNzA5LCANCkcuODcyIGFuZCBvdGhlciByZWNvbW1lbmRhdGlv bnMgZGV0YWlsZWRseS4gQXMgZm9yICBTZWN0aW9uIDQsIEkgZG9uJ3QgDQprbm93IHdoeSB5b3Ug c2FpZCB0aGF0IGl0IGlzIGNvcGllZCBmcm9tIElUVSBzdGFuZGFyZHMuICBJbiBTZWN0aW9uIDQs IGl0IA0KZGVzY3JpYmVzIHRoZSBjb25uZWN0aW9uIG1hbmFnZW1lbnQgbW9kZWwgZm9yIE9UTiBu ZXR3b3Jrcywgd2hpY2ggaXMgYmFzZWQgDQpvbiBvdXIgdW5kZXJzdGFuZGluZyBhbmQgc29tZSBk aXNjdXNzaW9ucyBpbiBJVFUtVCBRMTIuIA0KIA0KQmVzdCByZWdhcmRzLA0KTnVyaXQNCiANCiAN CiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGktZC1hbm5vdW5j ZS1ib3VuY2VzQGlldGYub3JnIA0KPiBbbWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgZXh0IA0KPiBJbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmcNCj4gU2Vu dDogRnJpZGF5LCBPY3RvYmVyIDE2LCAyMDA5IDExOjQ1IEFNDQo+IFRvOiBpLWQtYW5ub3VuY2VA aWV0Zi5vcmcNCj4gU3ViamVjdDogSS1EIEFjdGlvbjpkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1n NzA5LWZyYW1ld29yay0wMC50eHQgDQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSANCj4gSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0K PiANCj4gICAgIFRpdGxlICAgICAgICAgICA6IEZyYW1ld29yayBmb3IgR01QTFMgYW5kIFBDRSBD b250cm9sIA0KPiBvZiBHLjcwOSBPcHRpY2FsIFRyYW5zcG9ydCBOZXR3b3Jrcw0KPiAgICAgQXV0 aG9yKHMpICAgICAgIDogRi4gWmhhbmcsIGV0IGFsLg0KPiAgICAgRmlsZW5hbWUgICAgICAgIDog ZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDAudHh0DQo+ICAgICBQYWdl cyAgICAgICAgICAgOiAyNw0KPiAgICAgRGF0ZSAgICAgICAgICAgIDogMjAwOS0xMC0xNg0KPiAN Cj4gVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIGZyYW1ld29yayBmb3IgYXBwbHlpbmcgR2VuZXJh bGl6ZWQgTXVsaXQtDQo+IFByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoR01QTFMpIGFuZCB0aGUg UGF0aCBDb21wdXRhdGlvbiBFbGVtZW50IA0KPiAoUENFKSBhcmNoaXRlY3R1cmUgdG8gdGhlIGNv bnRyb2wgb2YgRy43MDkgT3B0aWNhbCBUcmFuc3BvcnQgTmV0d29ya3MgDQo+IChPVE4pIGFzIHNw ZWNpZmllZCBpbiB0aGUgSVRVLVQgRy43MDkgcmVjb21tZW5kYXRpb24sIGluY2x1ZGluZyB0aGUg DQo+IGVuaGFuY2VkIGZ1bmN0aW9uYWxpdHkgaW4gdGhlIHJlY2VudGx5IGNvbnNlbnRlZCByZXZp c2lvbi4gDQo+IA0KPiANCj4gDQo+IA0KPiB6aGFuZw0KPiANCj4gDQo+IA0KPiANCj4gDQo+ICAg RXhwaXJlcyBBcHJpbCAyMDEwDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gICBbcGFnZSAxXSANCj4g DQo+IGRyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAwLnR4dA0KPiANCj4g DQo+IA0KPiAgIE9jdG9iZXIgMjAwOSANCj4gDQo+IA0KPiBDb252ZW50aW9ucyB1c2VkIGluIHRo aXMgZG9jdW1lbnQgDQo+IA0KPiBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJF UVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsIA0KPiAiU0hPVUxEIiwgIlNIT1VMRCBOT1Qi LCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyANCj4gZG9jdW1l bnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0uDQo+IA0K PiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZzcNCj4gMDktZnJhbWV3 b3JrLTAwLnR4dA0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0K PiANCj4gQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFu dCBtYWlsIHJlYWRlcg0KPiBpbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZl IHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQ0KPiBJbnRlcm5ldC1EcmFmdC4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlz dA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2NhbXANCg0KDQo= --=_alternative 0025FA114825765E_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkhpIE51cml0LDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+SSBhZ3JlZSB3aXRoIHlvdS4g QWxsIGNvbnRlbnQgb2Ygc2VjdGlvbg0KMyBpbiB0aGlzIGRyYWZ0ICZuYnNwO2lzIGZyb20gRy43 MDkuIEluIG9yZGVyIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCBHLjcwOQ0KKGUuZy4sIE9EVTMgc2hv dWRsIG9jY3VweSA8Yj4zMTwvYj4gb2YgdGhlIDgwIFRTIGluIE9EVTQgYmFzZWQgb24gdGhlIGN1 cnJlbnQNCkcuNzA5IEFtZDMpLCBJIHN1Z2dlc3QgdGhlIHdob2xlIGNvbnRlbnQgYWJvdXQgRy43 MDkgYmUganVzdCByZWZlcmVkIHRvDQpHLjcwOSBvciBtb3ZlIHRvIHRoZSBBcHBlbmRpeC48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkJlc3QgUmVnYXJk cyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlhpaHVhIEZ1PC9m b250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5aVEUgQ29ycG9yYXRpb248 L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ PGI+JnF1b3Q7U3ByZWNoZXIsIE51cml0IChOU04NCi0gSUwvSG9kIEhhU2hhcm9uKSZxdW90OyAm bHQ7bnVyaXQuc3ByZWNoZXJAbnNuLmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtjY2FtcC1ib3VuY2VzQGlldGYub3Jn PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMTAtMjkgyc/O 5yAxMjozNjwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4mcXVvdDtleHQgRmF0YWkgWmhhbmcmcXVvdDsgJmx0O3poYW5nZmF0YWlAaHVhd2Vp LmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O0NsZW1lbnMsIFJhaW5lciBcKE5TTiAt IERFL011bmljaFwpJnF1b3Q7DQombHQ7cmFpbmVyLmNsZW1lbnNAbnNuLmNvbSZndDssICZxdW90 O1NvaW5pbmVuLCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtKb25uZQ0KXChOU04gLSBGSS9F c3Bvb1wpJnF1b3Q7ICZsdDtqb25uZS5zb2luaW5lbkBuc24uY29tJmd0OywgQ0NBTVAgJmx0O2Nj YW1wQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtDQ0FNUF0gSS1EIEFjdGlv bjpkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0wMC50eHQ8L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBm YWNlPSJBcmlhbCI+SGkgRmF0YWksPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVl IGZhY2U9IkFyaWFsIj5JIHRoaW5rIHRoYXQgaW4gdGhlIElFVEYgd2Ugc2hvdWxkDQpvbmx5IHB1 dCB0aGluZ3MgaW4gdGhlIG5vcm1hdGl2ZSBwYXJ0IG9mIHRoZSBkb2N1bWVudCB0aGF0IGlzIGFs c28gbm9ybWF0aXZlDQppbiBJVFUtVCwgaS5lLiBpbiB0aGlzIGNhc2Ugb25seSB3aGF0IGlzIHdy aXR0ZW4gaW4gdGhlIG5vcm1hdGl2ZSBzZWN0aW9ucw0KaW4gRy43MDkuIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+RXZlcnl0aGluZyBpbiBHLlN1cDQz IGNhbiBnbyBpbnRvDQphbiBhcHBlbmRpeCwgaS5lLiBtYXBwaW5ncyBvZiA0eCBPRFUyZSBpbnRv IE9EVTNlMS8yIGFuZCBldmVuIE9UVTJlIGxpbmUNCnNpZ25hbHMuIFdlIHNob3VsZCBhbHNvIG1l bnRpb24gd2hhdCBpcyB0aGUgYWN0dWFsIHN0YXR1cyBvZiB0aGUgRy5zdXA0My4NCjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+T3RoZXIgdGhpbmdzIHRo YXQgYXJlIGJlaW5nIGRpc2N1c3NlZA0KaW4gSVRVLVQgYW5kIGFyZSBub3QgYXBwcm92ZWQgc2hv dWxkIHN0YXkgY29tcGxldGVseSBvdXQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1i bHVlIGZhY2U9IkFyaWFsIj5CZXN0IHJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5OdXJpdCA8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8aHI+PGZv bnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+RnJvbTo8L2I+IGV4dCBGYXRhaSBaaGFuZyBbbWFp bHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbV0NCjxiPjxicj4NClNlbnQ6PC9iPiBNb25kYXksIE9j dG9iZXIgMjYsIDIwMDkgMjo1NiBQTTxiPjxicj4NClRvOjwvYj4gU3ByZWNoZXIsIE51cml0IChO U04gLSBJTC9Ib2QgSGFTaGFyb24pPGI+PGJyPg0KQ2M6PC9iPiBDbGVtZW5zLCBSYWluZXIgKE5T TiAtIERFL011bmljaCk7IENDQU1QOyBTb2luaW5lbiwgSm9ubmUgKE5TTg0KLSBGSS9Fc3Bvbyk7 IExpIERhbjsgaGFuIGppYW5ydWk7IGxpaGFuQGNoaW5hbW9iaWxlLmNvbTxiPjxicj4NClN1Ympl Y3Q6PC9iPiBSZTogSS1EIEFjdGlvbjpkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1nNzA5LWZyYW1l d29yay0wMC50eHQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0iQXJpYWwiPkhpIE51cml0LDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5i c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJBcmlhbCI+VGhhbmtzIGZvciB5b3Vy IGZ1cnRoZXIgY29tbWVudHMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj5XZSB0aGluayB3ZSBjYW4gbW92ZSB0aGUg Y29udGVudCBvZiBHLnN1cDQzDQp0byBhbiBhcHBlbmRpeCAoIGp1c3QgZm9yIGluZm9ybWF0aW9u KSwgYW5kIGV4cGxhaW4gdGhhdCB0aGlzIHBhcnQgb2YgaW5mb3JtYXRpb24NCmlzIG5vdCBjb25z ZW50ZWQgYnkgSVRVLVQgU0cxNS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQXJpYWwiPldlIGNhbiBhbHNvIHJlbW92ZSB0aGlz IGFwcGVuZGl4IGxhdGVyLCBpZg0KdGhpcyBkcmFmdCBpcyByZWFkeSB0byBiZSBSRkMgYW5kIHRo ZSBjb250ZW50IG9mIEcuc3VwNDMgaXMgc3RpbGwgbm90IGNvbnNlbnRlZA0KKGkuZS4sIG5vbi1z dGFuZGFyZCkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9IkFyaWFsIj5JcyBpdCBPSyBmb3IgeW91PyA6LSl+fn5+LCBJZiBZZXMs IHdlIHdpbGwNCnJlZmxlY3QgaXQgaW4gdGhlIG5leHQgdmVyc2lvbi48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0K PGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPlRoYW5rczwv Zm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5G YXRhaTxicj4NCiA8YnI+DQpBZHZhbmNlZCBUZWNobm9sb2d5IERlcGFydG1lbnQ8YnI+DQpXaXJl bGluZSBOZXR3b3JraW5nIEJ1c2luZXNzIFVuaXQ8YnI+DQpIdWF3ZWkgVGVjaG5vbG9naWVzIENv LiwgTFRELjxicj4NCkh1YXdlaSBCYXNlLCBCYW50aWFuLCBMb25nZ2FuZyw8YnI+DQpTaGVuemhl biA1MTgxMjkgUC5SLkNoaW5hPGJyPg0KVGVsOiArODYtNzU1LTI4OTcyOTEyPGJyPg0KRmF4OiAr ODYtNzU1LTI4OTcyOTM1PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4tLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PGI+RnJvbTo8L2I+IDwvZm9u dD48YSBocmVmPW1haWx0bzpudXJpdC5zcHJlY2hlckBuc24uY29tPjxmb250IHNpemU9MyBjb2xv cj1ibHVlPjx1PlNwcmVjaGVyLA0KTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbik8L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTM+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PGI+VG86PC9i PiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86emhhbmdmYXRhaUBodWF3ZWkuY29tPjxmb250IHNpemU9 MyBjb2xvcj1ibHVlPjx1PmV4dA0KRmF0YWkgWmhhbmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTM+IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PGI+Q2M6PC9iPiA8L2ZvbnQ+PGEgaHJlZj1t YWlsdG86cmFpbmVyLmNsZW1lbnNAbnNuLmNvbT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5D bGVtZW5zLA0KUmFpbmVyIChOU04gLSBERS9NdW5pY2gpPC91PjwvZm9udD48L2E+PGZvbnQgc2l6 ZT0zPiA7IDwvZm9udD48YSBocmVmPW1haWx0bzpjY2FtcEBpZXRmLm9yZz48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZT48dT5DQ0FNUDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4NCjsgPC9mb250 PjxhIGhyZWY9bWFpbHRvOmpvbm5lLnNvaW5pbmVuQG5zbi5jb20+PGZvbnQgc2l6ZT0zIGNvbG9y PWJsdWU+PHU+U29pbmluZW4sDQpKb25uZSAoTlNOIC0gRkkvRXNwb28pPC91PjwvZm9udD48L2E+ PGZvbnQgc2l6ZT0zPiA7IDwvZm9udD48YSBocmVmPW1haWx0bzpkYW5saUBodWF3ZWkuY29tPjxm b250IHNpemU9MyBjb2xvcj1ibHVlPjx1PkxpDQpEYW48L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTM+IDsgPC9mb250PjxhIGhyZWY9bWFpbHRvOmhhbmppYW5ydWlAaHVhd2VpLmNvbT48Zm9udCBz aXplPTMgY29sb3I9Ymx1ZT48dT5oYW4NCmppYW5ydWk8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTM+IDsgPC9mb250PjxhIGhyZWY9bWFpbHRvOmxpaGFuQGNoaW5hbW9iaWxlLmNvbT48Zm9udCBz aXplPTMgY29sb3I9Ymx1ZT48dT5saWhhbkBjaGluYW1vYmlsZS5jb208L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTM+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjxiPlNlbnQ6PC9iPiBGcmlk YXksIE9jdG9iZXIgMjMsIDIwMDkgOTo0MCBQTTwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PGI+ U3ViamVjdDo8L2I+IFJFOiBJLUQgQWN0aW9uOmRyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWc3MDkt ZnJhbWV3b3JrLTAwLnR4dDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJp YWwiPkhpIEZhdGFpLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPlRoYW5r cyBmb3IgeW91ciByZXNwb25zZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5SZWZlcnJpbmcg dG8gYSBkb2N1bWVudCB3aGljaCBpcyBub3QgYSBzdGFuZGFyZA0KaXMgcHJvYmxlbWF0aWMgYW5k IGV2ZW4gY29uZnVzaW5nLiBJIGFtIG5vdCBzdXJlIHRoYXQgYWxsIHRoZSBJRVRGIGNvbGxlYWd1 ZXMNCmNvdWxkIHJlYWxpemUgdGhhdCBhIHN1cHBsZW1lbnQgZG9jdW1lbnQgaW4gdGhlIElUVS1U IGlzIG5vdCBjb25zaWRlcmVkDQphcyBhIHN0YW5kYXJkLiBBcyB5b3UgYWdyZWVkIGJlbG93LCA8 dT5HLlN1cDQzIGlzIE5PVCBhIHN0YW5kYXJkPC91Pi4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJBcmlhbCI+SSBiZWxpZXZlIGl0IGlzIE5PVCBpbiB0aGUgc2NvcGUgb2YgQ0NBTVAN CnRvIGRlZmluZSB0aGUgZGF0YXBsYW5lIGJlaGF2aW9yIG9mIE9EVSBzd2l0Y2hpbmehrXdlIGNh biBkZWZpbmUgYSBjb250cm9sDQpwbGFuZSBmb3IgYSBzdGFuZGFyZCBkYXRhcGxhbmUgYW5kIHJl ZmVyIHRvIHRoZSBkYXRhcGxhbmUgc3RhbmRhcmQgYmVoYXZpb3IuDQo8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5PbmNlIChhbmQgaWYpIGl0IGlzIGRlZmluZWQgYXMgYSBz dGFuZGFyZA0KYmVoYXZpb3IgaW4gdGhlIElUVS1ULCB0aGVyZSB3aWxsIGJlIHJvb20gdG8gc3Bl Y2lmeSBhbiBleHRlbnNpb24gZm9yIEdNUExTDQooaWYgbmVjZXNzYXJ5KSB0byBzdXBwb3J0IGl0 LiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5BbHNvLCBJIHdvdWxkIGxpa2UgdG8gbm90ZSB0 aGF0IGl0IHdhcyBORVZFUg0KZGlzY3Vzc2VkIGluIFNHMS9RMTEgdG8gYWxsb3cgb3RoZXIgbWFw cGluZ3MgdGhhbiBPRFUyZSBpbnRvIE9EVTNlLiBJdA0Kd2FzIGV2ZW4gPGI+PGk+PHU+ZXhwbGlj aXRseSBzdGF0ZWQ8L3U+PC9pPjwvYj4gdGhhdCBubyBvdGhlciBtYXBwaW5nIHNob3VsZA0KYmUg ZGVzY3JpYmVkIGluIEcuU3VwNDMuIFRoZSBXUDMgcmVwb3J0IGZyb20gdGhlIHBsZW5hcnkgaW4g RGVjZW1iZXIgMjAwOA0Kc3RhdGVzIHRoYXQgOiZxdW90O0FmdGVyIGRpc2N1c3Npb24sIHRoZSBh Z3JlZW1lbnQgd2FzIHJlYWNoZWQgdG8gZG9jdW1lbnQNCnR3byB2ZXJzaW9ucyBvZiBPRFUzZSwg b25lIGJhc2VkIG9uIHRoZSBIdWF3ZWkgYW5kIENNQ0MgcHJvcG9zYWwgKHVzaW5nDQp0aGUgZXZl bnR1YWwgR01QIGNob3NlbiBmb3IgT0RVNCkgYW5kIHRoZSBvdGhlciBiYXNlZCBvbiB0aGUgTlRU IGFuZCBKYXBhbg0KcDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5y b3Bvc2Fscy4gJm5ic3A7QWdyZWVtZW50IHdhcw0KcmVhY2hlZCB0byA8Yj5vbmx5IGRvY3VtZW50 IHRoZSBtYXBwaW5nIG9mIGZvdXIgMTBHQkFTRS1SIGNsaWVudHM8L2I+IGludG8NCmVhY2ggb2Yg dGhlc2UgdHdvIHZlcnNpb25zIG9mIE9EVTNlIGluIGFuIHVwZGF0ZWQgRy5TdXA0My4mcXVvdDsu PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+TmV2ZXJ0 aGVsZXNzLCBldmVuIGlmIHNwZWNpZmllZA0KaW4gRy5TdXA0Mywgd2UgbmVlZCB0byBrZWVwIGlu IG1pbmQgdGhhdCB0aGlzIGlzIE5PVCBhIHN0YW5kYXJkIGFuZCB3ZQ0KY2Fubm90IHJlZmVyIHRv IGl0IGFzIHN1Y2guPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9 IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFj ZT0iQXJpYWwiPkJlc3QgcmVnYXJkcyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMw MDAwODAgZmFjZT0iQXJpYWwiPk51cml0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j MDAwMDgwIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8ZGl2IGFsaWduPWNlbnRlcj4NCjxi cj4NCjxocj48L2Rpdj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwv Yj4gZXh0IEZhdGFpIFpoYW5nIFttYWlsdG86emhhbmdmYXRhaUBodWF3ZWkuY29tXQ0KPGI+PGJy Pg0KU2VudDo8L2I+IEZyaWRheSwgT2N0b2JlciAyMywgMjAwOSA5OjQwIEFNPGI+PGJyPg0KVG86 PC9iPiBTcHJlY2hlciwgTnVyaXQgKE5TTiAtIElML0hvZCBIYVNoYXJvbik8Yj48YnI+DQpDYzo8 L2I+IENsZW1lbnMsIFJhaW5lciAoTlNOIC0gREUvTXVuaWNoKTsgQ0NBTVA7IFNvaW5pbmVuLCBK b25uZSAoTlNODQotIEZJL0VzcG9vKTsgTGkgRGFuOyBoYW4gamlhbnJ1aTsgbGloYW5AY2hpbmFt b2JpbGUuY29tPGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBJLUQgQWN0aW9uOmRyYWZ0LXpoYW5n LWNjYW1wLWdtcGxzLWc3MDktZnJhbWV3b3JrLTAwLnR4dDwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9IkFyaWFsIj5IaSBOdXJpdCw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJBcmlh bCI+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9 IkFyaWFsIj5QbGVhc2Ugc2VlIGJlbG93IGZvciBpbi1saW5lIHJlc3BvbnNlcy48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz aXplPTM+VGhhbmtzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+RmF0YWk8YnI+DQogPGJyPg0KQWR2 YW5jZWQgVGVjaG5vbG9neSBEZXBhcnRtZW50PGJyPg0KV2lyZWxpbmUgTmV0d29ya2luZyBCdXNp bmVzcyBVbml0PGJyPg0KSHVhd2VpIFRlY2hub2xvZ2llcyBDby4sIExURC48YnI+DQpIdWF3ZWkg QmFzZSwgQmFudGlhbiwgTG9uZ2dhbmcsPGJyPg0KU2hlbnpoZW4gNTE4MTI5IFAuUi5DaGluYTxi cj4NClRlbDogKzg2LTc1NS0yODk3MjkxMjxicj4NCkZheDogKzg2LTc1NS0yODk3MjkzNTwvZm9u dD4NCjxicj48Zm9udCBzaXplPTE+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0xPjxiPkZyb206PC9iPiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bnVy aXQuc3ByZWNoZXJAbnNuLmNvbT48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZT48dT5TcHJlY2hlciwN Ck51cml0IChOU04gLSBJTC9Ib2QgSGFTaGFyb24pPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0x PiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xPjxiPlRvOjwvYj4gPC9mb250PjxhIGhyZWY9bWFp bHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbT48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZT48dT56aGFu Z2ZhdGFpQGh1YXdlaS5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTE+DQo7IDwvZm9udD48 YSBocmVmPW1haWx0bzpkYW5saUBodWF3ZWkuY29tPjxmb250IHNpemU9MSBjb2xvcj1ibHVlPjx1 PmRhbmxpQGh1YXdlaS5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTE+DQo7IDwvZm9udD48 YSBocmVmPW1haWx0bzpoYW5qaWFucnVpQGh1YXdlaS5jb20+PGZvbnQgc2l6ZT0xIGNvbG9yPWJs dWU+PHU+aGFuamlhbnJ1aUBodWF3ZWkuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xPg0K OyA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bGloYW5AY2hpbmFtb2JpbGUuY29tPjxmb250IHNpemU9 MSBjb2xvcj1ibHVlPjx1PmxpaGFuQGNoaW5hbW9iaWxlLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MT4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTE+PGI+Q2M6PC9iPiA8L2ZvbnQ+PGEg aHJlZj1tYWlsdG86cmFpbmVyLmNsZW1lbnNAbnNuLmNvbT48Zm9udCBzaXplPTEgY29sb3I9Ymx1 ZT48dT5DbGVtZW5zLA0KUmFpbmVyIChOU04gLSBERS9NdW5pY2gpPC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0xPiA7IDwvZm9udD48YSBocmVmPW1haWx0bzpjY2FtcEBpZXRmLm9yZz48Zm9udCBz aXplPTEgY29sb3I9Ymx1ZT48dT5jY2FtcEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9MT4NCjsgPC9mb250PjxhIGhyZWY9bWFpbHRvOmpvbm5lLnNvaW5pbmVuQG5zbi5jb20+PGZv bnQgc2l6ZT0xIGNvbG9yPWJsdWU+PHU+U29pbmluZW4sDQpKb25uZSAoTlNOIC0gRkkvRXNwb28p PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xPiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xPjxi PlNlbnQ6PC9iPiBUaHVyc2RheSwgT2N0b2JlciAyMiwgMjAwOSAxOjQyIEFNPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MT48Yj5TdWJqZWN0OjwvYj4gUkU6IEktRCBBY3Rpb246ZHJhZnQtemhhbmct Y2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDAudHh0PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPkRlYXIgYXV0aG9ycywgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+VGhhbmtzIGZvciBzdWJtaXR0aW5nIHlvdXIgZG9jdW1lbnQNCm9uICZxdW90O0Zy YW1ld29yayBmb3IgR01QTFMgYW5kIFBDRSBDb250cm9sIG9mIEcuNzA5IE9wdGljYWwgVHJhbnNw b3J0DQpOZXR3b3JrcyZxdW90Oy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij5XZSBoYXZlIHJldmlld2VkIHRoZSBkb2N1bWVudCBhbmQgd2UNCmFyZSBhIGxpdHRsZSBiaXQg Y29uY2VybmVkIHRvIGZpbmQgb3V0IHRoYXQgc29tZSBzaWduaWZpY2FudCBpdGVtcyBkZXNjcmli ZWQNCmluIHRoZSBkb2N1bWVudCBhcmUgbm90IGFsaWduZWQgd2l0aCB3aGF0IGlzIGRlZmluZWQg aW4gRy43MDkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5i c3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+RXNwZWNpYWxs eSB0aGUgbWFwcGluZ3MgaW50byBPRFUzZTENCmFuZCBPRFUzZTIgYXJlIG9ubHkgZGVmaW5lZCBp biBHLlN1cDQzIHdoaWNoIGlzIG5vdCBhIHN0YW5kYXJkLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5JbiBhZGRpdGlvbiBHLlN1cDQzIGRvZXMgbm90IGRlZmlu ZQ0KbWFwcGluZ3Mgb2YgT0RVMCwgT0RVMSwgT0RVMiBhbmQgT0RVZmxleCBpbnRvIE9EVTNlMi4g VGhlIG9ubHkgbWFwcGluZ3MNCnRoYXQgYXJlIGRlZmluZWQgaW4gRy5TdXA0MyBhcmUgNHggT0RV MmUuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNw OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+W0ZhdGFp XSBZZXMsIHlvdSBhcmUgcmlnaHQgYW5kDQp3ZSBhbHNvIGluZGljYXRlZCBpbiB0aGlzIGRyYWZ0 IHRoYXQgT0RVM2UxIGFuZCBPRFUzZTIgYXJlIGRlZmluZWQgaW4gRy5TdXA0My4NCllvdSBrbm93 IEcuU3VwIGlzIG5vdCBzdGFuZGFyZCBjdXJyZW50bHksc28gSSB0aGluayB3ZSBoYXZlIHNvbWUg b3B0aW9ucw0KZm9yIHRoaXMuICgxKWFkZCBhIG5vdGUgdG8gZXhwbGFpbiB0aGF0IE9EVTNlMSBh bmQgT0RVM2UyIGFyZSBzdGlsbCBub24tc3RhbmRhcmQNCmV4cGxpY2l0bHkgKDIpIGNoYW5nZSB0 aGUgdGl0bGUgb2YgdGhpcyBkcmFmdCB0byAmcXVvdDtGcmFtZXdvcmsgZm9yIEdNUExTDQphbmQg UENFIENvbnRyb2wgb2YgT3B0aWNhbCBUcmFuc3BvcnQgTmV0d29ya3MmcXVvdDsgKDMpIG1vdmUg T0RVM2UyICZuYnNwO3RvDQphbiBhcHBlbmRpeC4gJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5JbiBhZGRpdGlvbiwgSSB0aGluayB3ZSBjYW4g Y292ZXINCk9EVTNlMSBhbmQgT0RVM2UyIGluIHRoaXMgZHJhZnQgYXQgdGhpcyBzdGFnZSAoaS5l LiwgaW5kaXZpZHVhbCBkcmFmdCksDQpiZWNhdXNlIHRoZXkgYXJlIGJlaW5nIGRldmVsb3BlZCBp biBJVFUtVCBhbmQgbWF5IGJlIGFjY2VwdGVkIGJ5IElUVS1UDQpzb21lIGRheS48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPkkgd2lsbCByZWZsZWN0IHRo aXMgaW4gdGhlIG5leHQNCnZlcnNpb24uIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PldlIGFyZSBhZnJhaWQgdGhhdCB0aGlzIGlzIG5vdCBpbmxpbmUNCndpdGggdGhlIHZpZXcgb2Yg dGhlIG1ham9yaXR5IG9mIHBhcnRpY2lwYW50cyBpbiBTRzE1L1ExMS48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPltGYXRhaV0gSSBkb24ndCBrbm93IHdoZXRoZXIg aXQNCmlzIHRydWUgb3Igbm90LiBCdXQgSSB0aGluayB3ZSBjYW4gaGVhciB0aGUgb3BpbmlvbnMg ZnJvbSBTRzE1L1ExMS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5FeGNl cHQgb2YgdGhlIGV4dGVuc2lvbnMgdGhhdCBhcmUgYWxyZWFkeQ0KZGVzY3JpYmVkIGluIHR3byBk cmFmdCAoZHJhZnQtY2VjY2FyZWxsaWZ1eGgtY2NhbXAtZ21wbHMtZXh0LWZvci1ldm9sLW90biwN CmRyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWV2b2x2aW5nLWc3MDkpLCBhbGwgb3RoZXIgY29udGVu dCBvZiBzZWN0aW9uIDMsDQo0IGlzIGNvcGllZCBmcm9tIElUVSBzdGFuZGFyZHMuIFdvdWxkIG5v dCBpdCBiZSBiZXR0ZXIgdG8ganVzdCByZWZlciB0bw0KdGhlIElUVS1UIGRvY3VtZW50PzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+W0ZhdGFpXSBJbiBTZWN0aW9u IDMsIHNvbWUgcGFydA0Kb2YgaW5mb3JtYXRpb24gaXMgZnJvbSBHLjcwOSBhbmQgRy44NzIgYW5k IHdlIHJlZmVyZW5jZSB0aGlzIHJlY29tbWVuZGF0aW9ucw0KZXhwbGljaXRseS4gV2UganVzdCB0 cnkgdG8gZ2l2ZSBhIGJyaWVmIG92ZXJ2aWV3IG9mIE9UTiB0byBDQ0FNUCBleHBlcnRzDQpmcm9t IHRoZSBwZXJzcGVjdGl2ZSBvZiBDb250cm9sIFBsYW5lIGFuZCBtYWtlIGV2ZXJ5b25lIHF1aWNr bHkgdW5kZXJzdGFuZA0Kd2h5IHdlIG5lZWQgbW9yZSBjb25zaWRlcmF0aW9ucyBvbiBPVE4gY29u dHJvbC4gSSB0aGluayBpdCBpcyByZWFsbHkgdG91Z2gNCmZvciBldmVyeW9uZSB0byBnbyB0aHJv dWdoIEcuNzA5LCBHLjg3MiBhbmQgb3RoZXIgcmVjb21tZW5kYXRpb25zIGRldGFpbGVkbHkuDQpB cyBmb3IgJm5ic3A7U2VjdGlvbiA0LCBJIGRvbid0IGtub3cgd2h5IHlvdSBzYWlkIHRoYXQgaXQg aXMgY29waWVkIGZyb20NCklUVSBzdGFuZGFyZHMuICZuYnNwO0luIFNlY3Rpb24gNCwgaXQgZGVz Y3JpYmVzIHRoZSBjb25uZWN0aW9uIG1hbmFnZW1lbnQNCm1vZGVsIGZvciBPVE4gbmV0d29ya3Ms IHdoaWNoIGlzIGJhc2VkIG9uIG91ciB1bmRlcnN0YW5kaW5nIGFuZCBzb21lIGRpc2N1c3Npb25z DQppbiBJVFUtVCBRMTIuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPkJl c3QgcmVnYXJkcyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5O dXJpdDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+ Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFs Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJp YWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZn dDsgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPiZndDsgRnJvbTogaS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmcNCjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgW21haWx0bzppLWQt YW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZ10NCk9uIEJlaGFsZiBPZiBleHQgPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBJbnRlcm5ldC1EcmFmdHNAaWV0 Zi5vcmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IFNl bnQ6IEZyaWRheSwgT2N0b2JlciAxNiwgMjAwOQ0KMTE6NDUgQU08L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IFN1YmplY3Q6 IEktRCBBY3Rpb246ZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDAudHh0 DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgQSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlDQpmcm9tIHRoZSBvbi1saW5lIDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9y aWVzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmbmJzcDsgJm5i c3A7IFRpdGxlICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7IDogRnJhbWV3b3Jr IGZvciBHTVBMUyBhbmQgUENFIENvbnRyb2wgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+Jmd0OyBvZiBHLjcwOSBPcHRpY2FsIFRyYW5zcG9ydCBOZXR3b3Jrczwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7ICZu YnNwOyBBdXRob3IocykgJm5ic3A7DQombmJzcDsgJm5ic3A7IDogRi4gWmhhbmcsIGV0IGFsLjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7ICZu YnNwOyBGaWxlbmFtZSAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7OiBkcmFmdC16aGFuZy1j Y2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0wMC50eHQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZuYnNwOyAmbmJzcDsgUGFnZXMgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyNzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7ICZuYnNwOyBEYXRlICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMjAwOS0xMC0xNjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgZnJhbWV3b3Jr DQpmb3IgYXBwbHlpbmcgR2VuZXJhbGl6ZWQgTXVsaXQtPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBQcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKEdNUExT KQ0KYW5kIHRoZSBQYXRoIENvbXB1dGF0aW9uIEVsZW1lbnQgPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAoUENFKSBhcmNoaXRlY3R1cmUgdG8gdGhlIGNv bnRyb2wNCm9mIEcuNzA5IE9wdGljYWwgVHJhbnNwb3J0IE5ldHdvcmtzIDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgKE9UTikgYXMgc3BlY2lmaWVkIGlu IHRoZSBJVFUtVA0KRy43MDkgcmVjb21tZW5kYXRpb24sIGluY2x1ZGluZyB0aGUgPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBlbmhhbmNlZCBmdW5jdGlv bmFsaXR5IGluIHRoZQ0KcmVjZW50bHkgY29uc2VudGVkIHJldmlzaW9uLiA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgemhhbmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPiZndDsgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+Jmd0OyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAmbmJzcDsgRXhw aXJlcyBBcHJpbCAyMDEwPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+Jmd0OyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7 IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgJm5ic3A7IFtwYWdlIDFdIDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1n NzA5LWZyYW1ld29yay0wMC50eHQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mZ3Q7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PiZndDsgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7ICZuYnNwOyBP Y3RvYmVyIDIwMDkgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ Jmd0OyAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgQ29u dmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPiZndDsgVGhlIGtleSB3b3JkcyAmcXVvdDtNVVNUJnF1b3Q7LA0KJnF1b3Q7 TVVTVCBOT1QmcXVvdDssICZxdW90O1JFUVVJUkVEJnF1b3Q7LCAmcXVvdDtTSEFMTCZxdW90Oywg JnF1b3Q7U0hBTEwNCk5PVCZxdW90OywgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+Jmd0OyAmcXVvdDtTSE9VTEQmcXVvdDssICZxdW90O1NIT1VMRA0KTk9UJnF1 b3Q7LCAmcXVvdDtSRUNPTU1FTkRFRCZxdW90OywgJnF1b3Q7TUFZJnF1b3Q7LCBhbmQgJnF1b3Q7 T1BUSU9OQUwmcXVvdDsNCmluIHRoaXMgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+Jmd0OyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQNCmFzIGRlc2Ny aWJlZCBpbiBbUkZDMjExOV0uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+Jmd0OyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4m Z3Q7IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0DQppczo8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWc3PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyAwOS1mcmFtZXdvcmstMDAudHh0PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUNCmJ5IGFub255bW91cyBGVFAgYXQ6PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBCZWxvdyBpcyB0 aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZQ0KYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZndDsgaW1wbGVtZW50 YXRpb24gdG8gYXV0b21hdGljYWxseQ0KcmV0cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24gb2YgdGhl PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jmd0OyBJbnRlcm5l dC1EcmFmdC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mZ3Q7 IDwvZm9udD48Zm9udCBzaXplPTI+PHR0Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KQ0NBTVAgbWFpbGluZyBsaXN0PGJyPg0KQ0NBTVBAaWV0Zi5v cmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wPGJyPg0K PC90dD48L2ZvbnQ+DQo8YnI+DQo= --=_alternative 0025FA114825765E_=-- From db3546@att.com Thu Oct 29 08:07:49 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2854C28C0D7 for ; Thu, 29 Oct 2009 08:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9U5JsYN7ve0 for ; Thu, 29 Oct 2009 08:07:48 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 464A03A6ABF for ; Thu, 29 Oct 2009 08:07:48 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-10.tower-167.messagelabs.com!1256828882!9190207!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 21349 invoked from network); 29 Oct 2009 15:08:03 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-10.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Oct 2009 15:08:03 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n9TF82c4029840 for ; Thu, 29 Oct 2009 11:08:02 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n9TF7x4j029830 for ; Thu, 29 Oct 2009 11:08:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Oct 2009 11:07:59 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 76 CCAMP Draft Agenda Thread-Index: AcpYqZopcdRz978+SGC7/UWp0rN+hA== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: Subject: [CCAMP] IETF 76 CCAMP Draft Agenda X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 15:07:49 -0000 CCAMP, Here's the draft agenda: http://www.ietf.org/proceedings/09nov/agenda/ccamp.htm Let us know if any comments. If you have a slot, please provide your slides no later than Nov. 9 (Monday). Deborah and Lou From richard.rabbat@gmail.com Thu Oct 29 11:22:39 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232FC3A69FE for ; Thu, 29 Oct 2009 11:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfF9NfGfoQ22 for ; Thu, 29 Oct 2009 11:22:38 -0700 (PDT) Received: from mail-iw0-f202.google.com (mail-iw0-f202.google.com [209.85.223.202]) by core3.amsl.com (Postfix) with ESMTP id 1F9C33A67A8 for ; Thu, 29 Oct 2009 11:22:38 -0700 (PDT) Received: by iwn40 with SMTP id 40so1738996iwn.32 for ; Thu, 29 Oct 2009 11:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=hw+I4Zh+mR/l8FtCz6vGJI86+lJZsjChbejiCqSrC6E=; b=q/VevK6upNpHCZVcXdkXHOMZJ3QwGm5qCWCvFkXY1GDoCW95pb0t9Hmt7Rnb6nurFa /y28wFhrteUOVHOiQcIjrUbrtNN+FrSmzQjHkN5YbPYewwGk2VJKemXVDgH5P2pFTy9f 2q3nkpQbnjVHV6YmSc6SYUDDfj9nQr21R5QaI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=A4hplPAD5O4UWmBb3ipzNWaC4rKLIFc0muo5TgBOigrY8Q1/6DQ+bOa2MarC+cl5Qf 5+eGwZOaUgay5iDAX191fx/DxKhXV86ewRdEGtWjNQcK+89ggqfuwDV93j0NeBLSeXTz dJMGN/qg6vIXBGgYSDW9qvFYLwLvnBsl9aUxc= MIME-Version: 1.0 Sender: richard.rabbat@gmail.com Received: by 10.231.28.143 with SMTP id m15mr1013941ibc.23.1256840571054; Thu, 29 Oct 2009 11:22:51 -0700 (PDT) In-Reply-To: <4AD74572.2070508@labn.net> References: <4AD74572.2070508@labn.net> Date: Thu, 29 Oct 2009 11:22:50 -0700 X-Google-Sender-Auth: 048abe4afd0f8afa Message-ID: From: Richard Rabbat To: Lou Berger Content-Type: multipart/alternative; boundary=00151774126cc6ed7a047716ffcf Cc: ccamp@ietf.org Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique resource identification X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 18:29:28 -0000 --00151774126cc6ed7a047716ffcf Content-Type: text/plain; charset=ISO-8859-1 sorry for the lag. do you want to describe your use-case further in terms of what you can't do and your proposed change? thanks, Richard. On Thu, Oct 15, 2009 at 8:53 AM, Lou Berger wrote: > Authors, > Have you given any additional thought on the repesentation of > tunable > lasers (and unique resource identification) beyond what is currently in > the draft? The current text is: > If the node has a tunable wavelength transponder, the tuning > wavelength is considered as a part of wavelength switching > operation. > > In the past, labels used for TE LSPs always represented a specific > resource that is uniquely identifiable by the node that allocates the > label and resource. Such unique identification is important/required > for certan restart and other corner cases. Your current definition works > fine for fixed lasers that can only be mapped to a single fiber. But, > the defined global label will not uniquely identify a resource on a node > when (a) tunable lasers are used, or (b) when a node supports multiple > fixed lasers that can be (optically) switched to a particular output > interface. > > What are your thoughts on how to provide such link-scoped unique > resource identification in the context of your draft? > > I don't think it'll be too difficult to address this critical point, and > see a couple of straightforward solutions if you'd like to discuss > off-line. > > Much thanks, > Lou > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --00151774126cc6ed7a047716ffcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable sorry for the lag.
do you want to describe your use-case further in term= s of what you can't do and your proposed change?
thanks,
Richard.=

On Thu, Oct 15, 2009 at 8:53 AM, Lou Ber= ger <lberger@labn.= net> wrote:
Authors,
=A0 =A0 =A0 =A0Have you given any additional thought on the repesentation = of tunable
lasers (and unique resource identification) beyond what is currently in
the draft? The current text is:
=A0 If the node has a tunable wavelength transponder, the tuning
=A0 wavelength is considered as a part of wavelength switching
=A0 operation.

In the past, labels used for TE LSPs always represented a specific
resource that is uniquely identifiable by the node that allocates the
label and resource. =A0Such unique identification is important/required
for certan restart and other corner cases. Your current definition works fine for fixed lasers that can only be mapped to a single fiber. =A0But, the defined global label will not uniquely identify a resource on a node when (a) tunable lasers are used, or (b) when a node supports multiple
fixed lasers that can be (optically) switched to a particular output
interface.

What are your thoughts on how to provide such link-scoped unique
resource identification in the context of your draft?

I don't think it'll be too difficult to address this critical point= , and
see a couple of straightforward solutions if you'd like to discuss off-= line.

Much thanks,
Lou


_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp

--00151774126cc6ed7a047716ffcf-- From lberger@labn.net Thu Oct 29 18:26:50 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F02DA3A6904 for ; Thu, 29 Oct 2009 18:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LUhm1H+KYGG for ; Thu, 29 Oct 2009 18:26:49 -0700 (PDT) Received: from outbound-mail-31.bluehost.com (outbound-mail-31.bluehost.com [69.89.18.151]) by core3.amsl.com (Postfix) with SMTP id C8EC73A686A for ; Thu, 29 Oct 2009 18:26:49 -0700 (PDT) Received: (qmail 27365 invoked by uid 0); 30 Oct 2009 01:27:05 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy2.bluehost.com with SMTP; 30 Oct 2009 01:27:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=iNXfLt9FpyzrejJMzz2gZpvivzZ6g9zMo0VdNRVQzE6LA1Adny0M0GIWS+W9dOYuUIOBQSN+NEO4qPk2uXCj/jGWSGhNWdF+ijWa9DPdzLzi5PSsJg4twR7DMsc56WD9; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N3gGf-0007MD-H0 for ccamp@ietf.org; Thu, 29 Oct 2009 19:27:05 -0600 Message-ID: <4AEA40F5.5050205@labn.net> Date: Thu, 29 Oct 2009 21:27:17 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 0.96a 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] Overdue announcement: Communications received from the OIF, 23rd July 2009 (1/2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 01:26:51 -0000 The following was sent to the CCAMP WG chairs on July 23rd, 2009. A URL to the original communication (pdf) can be found below. The text in the communication is also enclosed. This communication should have been announced prior to the last IETF. A full list of Communications and Liaisons to and from CCAMP can be found at: http://trac.tools.ietf.org/wg/ccamp/trac/wiki/CommsLiasons Lou ------------------------------------------------------------------ [http://trac.tools.ietf.org/wg/ccamp/trac/raw-attachment/ticket/14/oif2009.252.03.pdf] July 23, 2009 Mr. Lou Berger, lberger@labn.net, IETF CCAMP Coâ€Chair Ms. Deborah Brungard, dbrungard@att.com, IETF CCAMP Coâ€Chair Cc: Ross Callon, rcallon@juniper.net, IETF Routing Area Director David Ward, dward@cisco.com, IETF Routing Area Director From: Lyndon Ong, lyong@ciena.com, OIF Technical Committee Chair Dear Lou and Deborah, OIF has previously exchanged liaisons with IETF CCAMP WG regarding support of routing extensions to meet OIF members’ needs for optical network routing (see liaisons from OIF to CCAMP of Feb. 14, 2008 and Feb. 5, 2009 and associated responses from IETF CCAMP WG). Some of IETF CCAMP’s work following these interactions is being incorporated into OIF work, esp. a) The ability to specify additional identifiers for the endpoints of an advertised link, using the Local and Remote TE Router ID subâ€TLV defined in draft-ietf-ccamp-gmpls-ason-routing-ospf- 08.t b) The ability to specify node local prefixes (in OIF associated with client entities reachable from a particular link endpoint), using the Node Attribute TLV, and its Local TE Router ID and Node Local Prefix sub-TLVs, all defined in draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt. However, there continue to be some OIF requirements not yet met by the extensions defined in the above CCAMP work, as we understand it. OIF requests that IETF CCAMP consider additional extensions for the following: 1. Layer-scoped link attributes, including layer-specific bandwidth or connection availability In previous discussion with CCAMP, there may have been some miscommunication concerning what was meant by “layer-scoped” or “layer-specific”. An example is for a link that may be used for VC-3 or VC-4 connections, which are considered separate layers in the ITU-T model. An attribute such as number of available connections may not be accurately derivable from the overall link bandwidth due to issues with positioning of occupied timeslots. An attribute such as link metric and link resource class may either be identical for all layers supported by the link or be different depending on the specific layer network. Current protocol does not support specification of attributes in this level of detail. 2. Link associated local connection type In previous discussion with CCAMP, the use of the ISCD and IACD sub-TLVs was suggested as a way of advertising the ability of the link to either switch or terminate and adapt an incoming signal. We believe that the IACD, as defined in draft-ietf-ccamp-gmpls-mln-extensions-06.txt, may be very helpful for control of multi-layer/multi-region networks and will be looking at potential use of the IACD in future. However, we believe that ISCD/IACD may not be the best method of supporting the local connection type indication for the following reasons: - When both ISCD and IACD are present, it is possible to determine whether the endpoint supports Connection Point (CP) or Termination Connection Point (TCP) functionality or both. However, since only the ISCD is required to be always present, it is not possible to assure that this determination can be made. Also, if only the ISCD is received, it is ambiguous as to whether this should be interpreted as the endpoint supporting CP functionality only, or whether this should be interpreted as the endpoint (or associated routing controller) not supporting IACD. - The current application for local connection type in OIF is not related to multi-layer/multiregion but control plane use within a layer. It would be preferable to be able to advertise local connection type without requiring the receiver to also understand multi-layer/multi-region routing, and define a method for advertising local connection type that is separable from advertising adaptation capabilities. Local connection type also falls under the category of potentially layer-scoped link attributes discussed above. 3. Advertisement of node local prefixes using NSAP format CCAMP has approved extensions to the routing protocol to carry node local prefixes in IPv4 and IPv6 format, however OIF members have indicated that they see a need to advertise prefixes that are in other formats, especially in NSAP format. This is not currently supported by CCAMP documents. We would welcome opinions or guidance from CCAMP on these three points and look forward to proposals from interested parties in CCAMP to address these needs. Thank you for your continued attention. Best regards, Lyndon Ong OIF Technical Committee Chair From lberger@labn.net Thu Oct 29 18:26:53 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D9F128C0D8 for ; Thu, 29 Oct 2009 18:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbH17FEtW4aa for ; Thu, 29 Oct 2009 18:26:52 -0700 (PDT) Received: from outbound-mail-158.bluehost.com (outbound-mail-158.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 399C83A686A for ; Thu, 29 Oct 2009 18:26:52 -0700 (PDT) Received: (qmail 833 invoked by uid 0); 30 Oct 2009 01:27:08 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy5.bluehost.com with SMTP; 30 Oct 2009 01:27:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=dmLA+Xs2+f91SC3BzUtgWc3jNVuXApPaetC2mc9bc+IHYKfHWfnjo7wGEAEM8muLEP1TBgd81QOrRI5/1KIDLYNsz1Y0m98njFuBEttmL8xYfQT5pCCTL7MWhlnTaL+H; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N3gGi-0007N2-LM for ccamp@ietf.org; Thu, 29 Oct 2009 19:27:08 -0600 Message-ID: <4AEA40F8.1000208@labn.net> Date: Thu, 29 Oct 2009 21:27:20 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 0.96a 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] Overdue announcement: Communications received from the OIF, 23rd July 2009 (2/2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 01:26:53 -0000 The following was sent to the CCAMP WG chairs on July 23rd, 2009. A URL to the original communication (pdf) can be found below. The text in the communication is also enclosed. This communication should have been announced prior to the last IETF. A full list of Communications and Liaisons to and from CCAMP can be found at: http://trac.tools.ietf.org/wg/ccamp/trac/wiki/CommsLiasons Lou ------------------------------------------------------------------ [http://trac.tools.ietf.org/wg/ccamp/trac/raw-attachment/ticket/15/oif2009.247.05.pdf] July 23, 2009 Mr. Lou Berger, lberger@labn.net, IETF CCAMP Co-Chair Ms. Deborah Brungard, dbrungard@att.com, IETF CCAMP Co-Chair Cc: Ross Callon, rcallon@juniper.net, IETF Routing Area Director David Ward, dward@cisco.com, IETF Routing Area Director From: Lyndon Ong, lyong@ciena.com, OIF Technical Committee Chair Dear Lou and Deborah, OIF recently completed a worldwide interoperability demonstration. Among other functions, GMPLS RFC 4872 end-to-end recovery was used to control Full LSP Rerouting across multiple carrier domains, on three continents. Details are at http://www.oiforum.com/public/OIF_Networking_Demo_2009.html. The GMPLS protocol operated successfully. This liaison informs you of our findings on four aspects of the protocol, and solicits your comments. First, carriers were unable to allocate a globally unique association source address to each LSP originator. Available LSR addresses were unique only at carrier domain scope. In order to uniquely identify the association source, an experimental ASSOCIATION object was used that included a routing area ID to scope the association source address. In the past ccamp has insisted that globally unique addresses must be assigned to all GMPLS LSRs. We note that this continues to prove difficult when actually deploying worldwide GMPLS networks. Second, we found behaviour differences in error reporting and restoration triggering. Some implementations sent both Notify and PathErr detailing the fault location, others sent only Notify. Some implementations regarded the Notify as the trigger for restoration, others triggered on either message. Text in RFC 4872 section 11 indicates that the trigger is a "Notify and/or a PathErr". This text has been interpreted in different ways. Perhaps it could be clarified to indicate that either message individually, or the arrival of both messages within an interval, should be regarded as a single restoration trigger. Third, some implementations reported intermediate link failures using error code/sub-code 25/9 (Notify Error/LSP Failure) others 25/11 (Notify Error/LSP Locally Failed). RFC 4872 section 11 seems clear that 25/11 should be used to report an intermediate link failure for restoration. However, it seems strange not to trigger restoration procedures on receipt of errors that describe other faults. Fourth, some implementations used error code zero for administratively initiated graceful release of an LSP. We see that http://tools.ietf.org/html/draft-ietf-ccamp-mpls-graceful-shutdown-10#section-4.2 suggests error codes when the cause is link or node maintenance, but no suitable value exists to indicate an administrative LSP release for other reasons. We would welcome opinions or guidance from ccamp on these four points. If ccamp indicates that RFC errata or protocol updates are desirable, we would be glad to contribute. Best regards, Lyndon Ong OIF Technical Committee Chair From web-usrn@ISI.EDU Thu Oct 29 23:05:16 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4E73A6924 for ; Thu, 29 Oct 2009 23:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.227 X-Spam-Level: X-Spam-Status: No, score=-17.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLqPotriR7IY for ; Thu, 29 Oct 2009 23:05:15 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id BDBAE3A681E for ; Thu, 29 Oct 2009 23:05:15 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9U64LKt002449; Thu, 29 Oct 2009 23:04:22 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n9U64J4j002434; Thu, 29 Oct 2009 23:04:19 -0700 (PDT) Date: Thu, 29 Oct 2009 23:04:19 -0700 (PDT) Message-Id: <200910300604.n9U64J4j002434@boreas.isi.edu> To: jplang@ieee.org, yakov@juniper.net, dimitri.papadimitriou@alcatel-lucent.be, rcallon@juniper.net, adrian.farrel@huawei.com, lberger@labn.net, dbrungard@att.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] [Editorial Errata Reported] RFC4872 (1935) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 06:05:16 -0000 The following errata report has been submitted for RFC4872, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4872&eid=1935 -------------------------------------- Type: Editorial Reported by: Vishwas Manral Section: 15.3 Original Text ------------- - PRROs SHOULD be present in the Path message for the pre- provisioning of the secondary protecting LSP to enable recovery resource sharing between one or more secondary protecting LSPs (see Section 15.4). Corrected Text -------------- - PPROs SHOULD be present in the Path message for the pre- provisioning of the secondary protecting LSP to enable recovery resource sharing between one or more secondary protecting LSPs (see Section 15.4). Notes ----- PRRO -->> PPRO Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04) -------------------------------------- Title : RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery Publication Date : May 2007 Author(s) : J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou, Ed. Category : PROPOSED STANDARD Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG From Adrian.Farrel@huawei.com Fri Oct 30 03:45:47 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A5033A68C9 for ; Fri, 30 Oct 2009 03:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.98 X-Spam-Level: X-Spam-Status: No, score=-0.98 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_20=-0.74, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoyvqHvyLDYl for ; Fri, 30 Oct 2009 03:45:46 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 747763A6898 for ; Fri, 30 Oct 2009 03:45:46 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSB005F5PWQ0X@usaga03-in.huawei.com> for ccamp@ietf.org; Fri, 30 Oct 2009 05:46:03 -0500 (CDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSB00BFGPWNDL@usaga03-in.huawei.com> for ccamp@ietf.org; Fri, 30 Oct 2009 05:46:02 -0500 (CDT) Date: Fri, 30 Oct 2009 10:45:16 +0000 From: Adrian Farrel To: ccamp@ietf.org Message-id: <2CC2532E76A04BAAA275693B032C6BCD@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Cc: =?iso-8859-1?Q?Alfred_H=CEnes?= Subject: [CCAMP] RFC 4207 LMP Erratum X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 10:45:47 -0000 Hi CCAMP, Can I please have your help in resolving an Erratum raised against the LMP spec RFC 4207. You can see the full details at http://www.rfc-editor.org/errata_search.php?rfc=4207&eid=167 The essence of the question is: how many objects may be present on a ? The BNF in section 4.1.1 currently implies just one. But the text could be interpreted to man more than one. While you are looking at this, can you say whether any other messages should also allow more than one object? Many thanks, Adrian From lberger@labn.net Fri Oct 30 06:02:00 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0CA23A6962 for ; Fri, 30 Oct 2009 06:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.137 X-Spam-Level: X-Spam-Status: No, score=-2.137 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+mb8BkZ4zm4 for ; Fri, 30 Oct 2009 06:01:59 -0700 (PDT) Received: from outbound-mail-133.bluehost.com (outbound-mail-133.bluehost.com [67.222.39.23]) by core3.amsl.com (Postfix) with SMTP id BEEB93A683D for ; Fri, 30 Oct 2009 06:01:59 -0700 (PDT) Received: (qmail 8360 invoked by uid 0); 30 Oct 2009 13:02:16 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy4.bluehost.com with SMTP; 30 Oct 2009 13:02:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=pt0KyEw7RVPT2spBu8X1P8n00DlQf/FQO6FYTmt6mLDOt0aSFkth34Q927Yrmg4XZmBy0Im5z+60Giifn4YVK+T6neQMDfYhNk4aTTvsmKdTidJyCJYwrcYCDb43p24i; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N3r7Q-0006WU-EO; Fri, 30 Oct 2009 07:02:16 -0600 Message-ID: <4AEAE3E4.1050309@labn.net> Date: Fri, 30 Oct 2009 09:02:28 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Richard Rabbat References: <4AD74572.2070508@labn.net> In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique resource identification X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 13:02:00 -0000 Richard, Okay let me try again with a specific case. If I have an rro or ero that identifies the label (lambda) per your document, how does a node know which laser the label corresponds to when all lasers in the system are tunable? Thanks, Lou On 10/29/2009 2:22 PM, Richard Rabbat wrote: > sorry for the lag. > do you want to describe your use-case further in terms of what you can't > do and your proposed change? > thanks, > Richard. > > On Thu, Oct 15, 2009 at 8:53 AM, Lou Berger > wrote: > > Authors, > Have you given any additional thought on the repesentation of > tunable > lasers (and unique resource identification) beyond what is currently in > the draft? The current text is: > If the node has a tunable wavelength transponder, the tuning > wavelength is considered as a part of wavelength switching > operation. > > In the past, labels used for TE LSPs always represented a specific > resource that is uniquely identifiable by the node that allocates the > label and resource. Such unique identification is important/required > for certan restart and other corner cases. Your current definition works > fine for fixed lasers that can only be mapped to a single fiber. But, > the defined global label will not uniquely identify a resource on a node > when (a) tunable lasers are used, or (b) when a node supports multiple > fixed lasers that can be (optically) switched to a particular output > interface. > > What are your thoughts on how to provide such link-scoped unique > resource identification in the context of your draft? > > I don't think it'll be too difficult to address this critical point, and > see a couple of straightforward solutions if you'd like to discuss > off-line. > > Much thanks, > Lou > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > From lberger@labn.net Fri Oct 30 06:47:20 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E143A6AB4 for ; Fri, 30 Oct 2009 06:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Gj92H1VSKHR for ; Fri, 30 Oct 2009 06:47:19 -0700 (PDT) Received: from outbound-mail-133.bluehost.com (outbound-mail-133.bluehost.com [67.222.39.23]) by core3.amsl.com (Postfix) with SMTP id 2D04B3A68ED for ; Fri, 30 Oct 2009 06:47:19 -0700 (PDT) Received: (qmail 15831 invoked by uid 0); 30 Oct 2009 13:47:36 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy4.bluehost.com with SMTP; 30 Oct 2009 13:47:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=cnWAHydK+ci+Hz6G3fAb/FqkXo9/xuqpJ+y3XrC3JTWultCf7wiWNpnTFF2a8rPt9hNL+L4niscF4ZReChIUYaZBlFGZ1UQzuAr2AC5hFKbQ1ivS8cW6iJ6+VwhZ6Lw/; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1N3rpG-0002sL-BS; Fri, 30 Oct 2009 07:47:34 -0600 Message-ID: <4AEAEE82.7050306@labn.net> Date: Fri, 30 Oct 2009 09:47:46 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: CCAMP References: <002601ca5724$9a0f65e0$ce2e31a0$@co.uk> In-Reply-To: <002601ca5724$9a0f65e0$ce2e31a0$@co.uk> X-Enigmail-Version: 0.96a 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: "Brungard, Deborah A, ALABS" Subject: [CCAMP] WG Trac Page & Communications/Liaisons X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 13:47:20 -0000 All, As some of you may have noticed, the Wiki has a page that lists "Communications and Liaisons to and from CCAMP", http://trac.tools.ietf.org/wg/ccamp/trac/wiki/CommsLiasons. This is pretty much just an updated version of the page Adrian started. In addition to this page, we've started tracking Liaisons&Communication in one additional fashion, via Trac. The Wiki mentioned by Dan below is part of a largely standard Trac installation, which also includes support for issues (aka "tickets" in trac) tracking. The WG chairs have been transitioning over to the trac ticket system for post-wg last call document tracking. We've started also using this system to track the status of incoming liaisons and communications. Our use of Trac is still a work-in-progress; so comments and suggested changes or additions are most welcome. The current open tickets can be found at http://trac.tools.ietf.org/wg/ccamp/trac/report/3. All liaisons and communications will continue to be announced on the WG mail list. Lou (and Deborah) On 10/27/2009 12:43 PM, Daniel King wrote: > Hello all, > > For you viewing pleasure, we have created a Wiki for the CCAMP Supplemental > Information. This new Wiki replaces the previous CCAMP Supplemental > Information site (http://ccamp.labn.net/). The Wiki can be accessed by > clicking the "Wiki" link at the top of the IETF CCAMP Status Pages, or by > going directly to the following URL: > > http://trac.tools.ietf.org/wg/ccamp/trac/wiki > > The new Wiki contains the following CCAMP Supplemental Information and > links: > > - CCAMP Charter > - Mailing List Archive > - CCAMP Status Page (With document summary information and links to minutes) > - Working group document issues/status list > - Communications and Liaisons > - Temporary Codepoint Registries > > Please feel free to send me, or the co-chairs, suggestions for new content > or links for our Wiki. > > Best regards, > Dan > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From gregb@grotto-networking.com Fri Oct 30 12:03:38 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 063C93A6767 for ; Fri, 30 Oct 2009 12:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7rM3zkrKU8y for ; Fri, 30 Oct 2009 12:03:37 -0700 (PDT) Received: from mail16c40.carrierzone.com (mail16c40.carrierzone.com [209.235.156.156]) by core3.amsl.com (Postfix) with ESMTP id DBA973A696D for ; Fri, 30 Oct 2009 12:03:36 -0700 (PDT) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by mail16c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id n9UJ3VJI020975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Oct 2009 19:03:35 GMT Message-ID: <4AEB3881.5090909@grotto-networking.com> Date: Fri, 30 Oct 2009 12:03:29 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: tsbsg15@itu.int References: <20091027220943.81AD53A6A4A@core3.amsl.com> In-Reply-To: <20091027220943.81AD53A6A4A@core3.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: greg.jones@itu.int, ccamp@ietf.org, malcolm.betts@huawei.com, yoichi.maeda@ntt-at.co.jp, sjtrowbridge@alcatel-lucent.com, hiroshi.ota@itu.int, adrian.farrel@huawei.com, rcallon@juniper.net, paf@cisco.com, dbrungard@att.com Subject: Re: [CCAMP] New Liaison Statement, "LS86 - Comments on WSON Impairment Work in CCAMP" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 19:03:38 -0000 Hi folks, I just reviewed this liaison (LS-86) and had a few questions and thoughts (from a individual perspective not IETF, CCAMP...). In section 3.1.1 of the WSON Impairments Framework draft we categorize the different types of impairment aware RWA computations. This section does not address "black links". In section 3.1.2 we discuss impairment information sharing constraints. This section includes the information sharing constraints of a "black link". From our understanding of the "black link" concept, no impairment parameters would be available for the control plane to share with computational entities for the subnetwork. We did not take this to mean that the owner of the "black link" would not know whether a path across that link was viable, or that all paths across the black link are viable. From our understanding of "black links" it did not appear that every black link must be terminated by 3R regenerators as stated in the liaison: "“black link” is a viable pre engineered optical path between 3R regenerators". We assumed that a black link could terminate on a receiver. Hence we took a more general view of a black link as an network element with unknown impairment properties whose impairment effects could be calculated by its owner (not the general control plane). Best Regards Greg B. Greg Jones(ITU-T SG 15) wrote: > Title: LS86 - Comments on WSON Impairment Work in CCAMP > Submission Date: 2009-10-27 > URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=603 > Please reply by 2010-05-31 > > From: Greg Jones(ITU-T SG 15) > To: IETF ccamp Working Group(dbrungard@att.com,lberger@labn.net) > Cc: paf@cisco.com > adrian.farrel@huawei.com > rcallon@juniper.net > ccamp@ietf.org > yoichi.maeda@ntt-at.co.jp > sjtrowbridge@alcatel-lucent.com > Reponse Contact: tsbsg15@itu.int > greg.jones@itu.int > hiroshi.ota@itu.int > Technical Contact: malcolm.betts@huawei.com > Purpose: For comment > Body: > Attachment(s): > LS86 - Comments on WSON Impairment Work in CCAMP - pdf (https://datatracker.ietf.org/documents/LIAISON/file719.pdf) > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From db3546@att.com Fri Oct 30 13:31:49 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DCB33A67BD for ; Fri, 30 Oct 2009 13:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fk11dEOospWi for ; Fri, 30 Oct 2009 13:31:48 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 99A5C3A6778 for ; Fri, 30 Oct 2009 13:31:48 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-8.tower-129.messagelabs.com!1256934724!35195547!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 18899 invoked from network); 30 Oct 2009 20:32:04 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Oct 2009 20:32:04 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n9UKW3p0029948; Fri, 30 Oct 2009 16:32:03 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n9UKVvNc029887; Fri, 30 Oct 2009 16:31:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Oct 2009 16:31:55 -0400 Message-ID: In-Reply-To: <4AEB3881.5090909@grotto-networking.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] New Liaison Statement, "LS86 - Comments on WSON Impairment Work in CCAMP" Thread-Index: AcpZk7mYv4arHiUrQBiKVHDwjqOD4gACG12w References: <20091027220943.81AD53A6A4A@core3.amsl.com> <4AEB3881.5090909@grotto-networking.com> From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "Greg Bernstein" , Cc: greg.jones@itu.int, ccamp@ietf.org, malcolm.betts@huawei.com, yoichi.maeda@ntt-at.co.jp, sjtrowbridge@alcatel-lucent.com, hiroshi.ota@itu.int, adrian.farrel@huawei.com, rcallon@juniper.net, paf@cisco.com Subject: Re: [CCAMP] New Liaison Statement, "LS86 - Comments on WSON Impairment Work in CCAMP" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 20:31:49 -0000 All, Please note this email is outside of the ITU-IETF Liaison process and is not a formal response from CCAMP. Please treat as such. CCAMP, The proper ITU-IETF Liaison procedure is to first discuss the response within the Working Group and then for the Chairs to convey the Working Group response. We welcome all input for responding to Liaisons. Please direct input to the CCAMP list. Deborah and Lou -----Original Message----- From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Friday, October 30, 2009 3:03 PM To: tsbsg15@itu.int Cc: BRUNGARD, DEBORAH A (ATTLABS); lberger@labn.net; hiroshi.ota@itu.int; greg.jones@itu.int; ccamp@ietf.org; malcolm.betts@huawei.com; yoichi.maeda@ntt-at.co.jp; sjtrowbridge@alcatel-lucent.com; paf@cisco.com; adrian.farrel@huawei.com; rcallon@juniper.net Subject: Re: [CCAMP] New Liaison Statement, "LS86 - Comments on WSON Impairment Work in CCAMP" Hi folks, I just reviewed this liaison (LS-86) and had a few questions=20 and thoughts (from a individual perspective not IETF, CCAMP...). In section 3.1.1 of the WSON Impairments Framework draft we categorize=20 the different types of impairment aware RWA computations. This section=20 does not address "black links". In section 3.1.2 we discuss impairment information sharing constraints.=20 This section includes the information sharing constraints of a "black=20 link". From our understanding of the "black link" concept, no impairment parameters would be available for the control plane to share with=20 computational entities for the subnetwork. We did not take this to mean=20 that the owner of the "black link" would not know whether a path across=20 that link was viable, or that all paths across the black link are viable. From our understanding of "black links" it did not appear that every=20 black link must be terminated by 3R regenerators as stated in the=20 liaison: ""black link" is a viable pre engineered optical path between=20 3R regenerators". We assumed that a black link could terminate on a=20 receiver. Hence we took a more general view of a black link as an=20 network element with unknown impairment properties whose impairment=20 effects could be calculated by its owner (not the general control plane). Best Regards Greg B. Greg Jones(ITU-T SG 15) wrote: > Title: LS86 - Comments on WSON Impairment Work in CCAMP > Submission Date: 2009-10-27 > URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=3D603=20 > Please reply by 2010-05-31 > > From: Greg Jones(ITU-T SG 15) > To: IETF ccamp Working Group(dbrungard@att.com,lberger@labn.net) > Cc: paf@cisco.com > adrian.farrel@huawei.com > rcallon@juniper.net > ccamp@ietf.org > yoichi.maeda@ntt-at.co.jp > sjtrowbridge@alcatel-lucent.com > Reponse Contact: tsbsg15@itu.int > greg.jones@itu.int > hiroshi.ota@itu.int > Technical Contact: malcolm.betts@huawei.com > Purpose: For comment=20 > Body:=20 > Attachment(s): > LS86 - Comments on WSON Impairment Work in CCAMP - pdf (https://datatracker.ietf.org/documents/LIAISON/file719.pdf) > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 From fu.xihua@zte.com.cn Fri Oct 30 22:33:55 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43D143A68C5 for ; Fri, 30 Oct 2009 22:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.662 X-Spam-Level: X-Spam-Status: No, score=-100.662 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REfOYNV2jb3G for ; Fri, 30 Oct 2009 22:33:53 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id BAC613A69CF for ; Fri, 30 Oct 2009 22:33:52 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 9110473195744; Sat, 31 Oct 2009 13:13:46 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 16639.473195744; Sat, 31 Oct 2009 13:21:05 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n9V5Y8Kk037218 for ; Sat, 31 Oct 2009 13:34:08 +0800 (CST) (envelope-from fu.xihua@zte.com.cn) To: ccamp@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Sat, 31 Oct 2009 13:35:09 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-10-31 13:34:00, Serialize complete at 2009-10-31 13:34:00 Content-Type: multipart/alternative; boundary="=_alternative 001E93AD48257660_=" X-MAIL: mse1.zte.com.cn n9V5Y8Kk037218 Subject: [CCAMP] Comments about OTN control drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2009 05:33:55 -0000 This is a multipart message in MIME format. --=_alternative 001E93AD48257660_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQpSRkMzNjMwIGRlZmluZXMgdGhlIE1heGltdW0gQmFuZHdpZHRoIGFuZCAgVW5y ZXNlcnZlZCBCYW5kd2lkdGguIFJGQzQyMDIgDQphbmQgUkZDNDIwMyBkZWZpbmUgSW50ZXJmYWNl IFN3aXRjaGluZyBDYXBhYmlsaXR5IERlc2NyaXB0b3IgKElTQ0QpIA0KaW5jbHVkaW5nIE1heCBM U1AgQmFuZHdpZHRoIGF0IHByaW9yaXR5IHAgYW5kIE1pbmltdW0gTFNQIEJhbmR3aWR0aCBpbiB0 aGUgDQpTd2l0Y2hpbmcgQ2FwYWJpbGl0eSBzcGVjaWZpYyBpbmZvcm1hdGlvbiBmaWVsZC4NCg0K KDEpIEZvbGxvd2luZyBjb21tZW50cyBhcmUgYWJvdXQgDQpkcmFmdC1jZWNjYXJlbGxpLWNjYW1w LWdtcGxzLW9zcGYtZzcwOS0wMC50eHQuDQpTd2l0Y2hpbmcgQ2FwYWJpbGl0eS1zcGVjaWZpYyBp bmZvcm1hdGlvbiBpcyBpbmZlcmVkIGJ5IGEgbmV3IFN3aXRjaGluZyANCkNhcGFiaWxpdHkgKGku ZS4sICJFdm9sdmVkIE9UTiIgKSBkZWZpbmVkIGluIA0KZHJhZnQtY2VjY2FyZWxsaS1jY2FtcC1n bXBscy1vc3BmLWc3MDktMDAudHh0LiBUaGlzIG1ldGhvZCBsYWNrcyBvZiANCmdlbmVyYWwgcHVy cG9zZS4NCkNhbiB3ZSB1c2UgdGhlIGN1cnJlbnQgZXh0ZW5zaW9ucyBkZWZpbmVkIGluIFJGQzM2 MzAgYW5kIFJGQzQyMDIgdG8gbWVldCANCnRoZSByZXF1aXJlbWVudCB3aGljaCBpcyBwb2ludGVk IG91dCBpbiB0aGVzZSBkcmFmdHMgPw0KT25lIG9wdGlvbiBpcyB0byBhZHZlcnRpc2UgbXVsdGlw bGUgSVNDRCBzdWItVExWcyB3aXRoaW4gYSBzaW5nbGUgTGluayBUTFYgDQpmb3IgdGhlIGxpbmsu IEJ1dCBpbmZvcm1hdGlvbiBpcyByZXBlYXRlZCBmb3IgZWFjaCBMTyBPRFUgc2lnbmFsIHR5cGUu IA0KQXNsbyB0aGVyZSBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIGZvciBjb21wb3NlZCBzaWdu YWwgY29tcHV0YXRpb24uDQoxLiBGb3IgZXhhbXBsZSwgaW4gb3JkZXIgdG8gcmVwcmVzZW50IG9u ZSBpbnRlcmZhY2UgcG9ydCBvZiB0aGUgT0RVNC9PVFU0IA0KVEUgbGluayB3aXRoIDIuNUcgVFMg d2hpY2ggb25seSBzdXBwb3J0cyBPRFUzIG9yIE9EVTIsIHRoZXJlIGNhbiBiZSB0aHJlZSANCklT Q0RzLg0KVGhlIHNpemUgb2YgdHJpYnV0YXJ5IHNsb3QgY2FuIGJlIGluZmVyZWQgYnkgdGhlIE1p biBMU1AgQmFuZHdpZHRoIGluIHRoZSANCklTQ0QgMS4gTE8gT0RVIHNpZ25hbCB0eXBlcyBzdXBw b3J0ZWQgYnkgdGhlIGludGVyZmFjZSBwb3J0IGNhbiBiZSBpbmZlcmVkIA0KYnkgdGhlIElTQ0Qg MiBhbmQgSVNDRCAzLg0KICAgICBNYXhpbXVtIEJhbmR3aWR0aCA9IEJhbmR3aWR0aCBvZiBPRFU0 ICgyMzkvMjI3IKHBIDk5IDUzMiA4MDAga2JpdC9zIA0KKy8tIDIwIHBwbSkvT1RVNCAoZS5nIDI1 NS8yMjcgocEgOTkgNTMyIDgwMCBrYml0L3MgKy8tMjAgcHBtKQ0KICAgICBJbnRlcmZhY2UgU3dp dGNoaW5nIENhcGFiaWxpdHkgRGVzY3JpcHRvciAxOg0KICAgICAgICAgSW50ZXJmYWNlIFN3aXRj aGluZyBDYXBhYmlsaXR5ID0gVERNDQogICAgICAgICBFbmNvZGluZyA9IEcuNzA5IE9EVWsgKERp Z2l0YWwgUGF0aCkNCiAgICAgICAgIE1pbiBMU1AgQmFuZHdpZHRoID0gMi41RyBUUw0KICAgICAg ICAgTWF4IExTUCBCYW5kd2lkdGhbcF0gPSBPRFU0L09UVTQsIGZvciBhbGwgcA0KICAgICAgICAg LA0KICAgICBJbnRlcmZhY2UgU3dpdGNoaW5nIENhcGFiaWxpdHkgRGVzY3JpcHRvciAyOg0KICAg ICAgICAgSW50ZXJmYWNlIFN3aXRjaGluZyBDYXBhYmlsaXR5ID0gVERNDQogICAgICAgICBFbmNv ZGluZyA9IEcuNzA5IE9EVWsgKERpZ2l0YWwgUGF0aCkNCiAgICAgICAgIE1pbiBMU1AgQmFuZHdp ZHRoID0gT0RVMg0KICAgICAgICAgTWF4IExTUCBCYW5kd2lkdGhbcF0gPSBPRFUyICwgZm9yIGFs bCBwDQoNCiAgICAgICAgIEludGVyZmFjZSBTd2l0Y2hpbmcgQ2FwYWJpbGl0eSBEZXNjcmlwdG9y IDM6DQogICAgICAgICBJbnRlcmZhY2UgU3dpdGNoaW5nIENhcGFiaWxpdHkgPSBURE0NCiAgICAg ICAgIEVuY29kaW5nID0gRy43MDkgT0RVayAoRGlnaXRhbCBQYXRoKQ0KICAgICAgICAgTWluIExT UCBCYW5kd2lkdGggPSBPRFUzDQogICAgICAgICBNYXggTFNQIEJhbmR3aWR0aFtwXSA9IE9EVTMg LCBmb3IgYWxsIHANCg0KMi4gQW5vdGhlciBleGFtcGxlLCBpbiBvcmRlciB0byByZXByZXNlbnQg b25lIGludGVyZmFjZSBwb3J0IG9mIHRoZSANCk9EVTMvT1RVMyBURSBsaW5rIGxpbmsgd2l0aCAx LjI1RyBUUyB3aGljaCBvbmx5IHN1cHBvcnRzIE9EVTIsIHRoZXJlIGNhbiANCmJlIHR3byBJU0NE cy4NClRoZSBzaXplIG9mIHRyaWJ1dGFyeSBzbG90IGNhbiBiZSBpbmZlcmVkIGJ5IHRoZSBNaW4g TFNQIEJhbmR3aWR0aCBpbiB0aGUgDQpJU0NEIDEuIExPIE9EVSBzaWduYWwgdHlwZXMgc3VwcG9y dGVkIGJ5IHRoZSBpbnRlcmZhY2UgcG9ydCBjYW4gYmUgaW5mZXJlZCANCmJ5IHRoZSBJU0NEIDIg YW5kIElTQ0QgMy4NCiAgICAgIE1heGltdW0gQmFuZHdpZHRoID0gQmFuZHdpZHRoIG9mIE9EVTMg KDIzOS8yMzYgocEgMzkgODEzIDEyMCBrYml0L3MgDQorLy0gMjAgcHBtKS9PVFUzIChlLmcgMjU1 LzIzNiChwSAzOSA4MTMgMTIwIGtiaXQvcyArLy0yMCBwcG0pDQogICAgICBJbnRlcmZhY2UgU3dp dGNoaW5nIENhcGFiaWxpdHkgRGVzY3JpcHRvciAxOg0KICAgICAgICAgSW50ZXJmYWNlIFN3aXRj aGluZyBDYXBhYmlsaXR5ID0gVERNDQogICAgICAgICBFbmNvZGluZyA9IEcuNzA5IE9EVWsgKERp Z2l0YWwgUGF0aCkNCiAgICAgICAgIE1pbiBMU1AgQmFuZHdpZHRoID0gMS4yNUcgVFMNCiAgICAg ICAgIE1heCBMU1AgQmFuZHdpZHRoW3BdID0gT0RVMy9PVFUzLCBmb3IgYWxsIHANCg0KICAgICAg SW50ZXJmYWNlIFN3aXRjaGluZyBDYXBhYmlsaXR5IERlc2NyaXB0b3IgMjoNCiAgICAgICAgIElu dGVyZmFjZSBTd2l0Y2hpbmcgQ2FwYWJpbGl0eSA9IFRETQ0KICAgICAgICAgRW5jb2RpbmcgPSBH LjcwOSBPRFVrIChEaWdpdGFsIFBhdGgpDQogICAgICAgICBNaW4gTFNQIEJhbmR3aWR0aCA9IE9E VTINCiAgICAgICAgIE1heCBMU1AgQmFuZHdpZHRoW3BdID0gT0RVMiAsIGZvciBhbGwgcA0KDQpB bm90aGVyIG9wdGlvbiBpcyBkZWZpbmVkIGluIE9JRiAgRS1OTkkgMi4wLiBJdCBkZWZpbmVkIHRo ZSBmb2xsb3dpbmcgDQpleHRlbnNpb24gZm9yIFNESCBhbmQgT0RVay4gQnV0IEkgdGhpayB0aGVy ZSBpcyBub3QgZW5vdWdoIGluZm9ybWF0aW9uIGZvciANCnRoZSBwcmVlbXB0IGNvbXB1dGF0aW9u IGRlZmluZWQgaW4gW1JGQzMyMDldLg0KDQogICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K ICAgICAgfCAgICAgICAgVHlwZSAoRVhQKSAgICAgICAgICAgICB8ICAgICAgICBMZW5ndGggPSA0 ICsgbio0ICAgICAgIHwNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICB8IFN3aXRjaGluZyBDYXAgfCAg IEVuY29kaW5nICAgIHwgICAgICAgICAgIFJlc2VydmVkICAgICAgICAgICAgfA0KICAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCiAgICAgIHwgIFNpZ25hbCBUeXBlICB8ICAgICAgICBOdW1iZXIgb2YgVW5hbGxvY2F0 ZWQgVGltZXNsb3RzICAgICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgfCAgU2lnbmFsIFR5 cGUgIHwgICAgICAgIE51bWJlciBvZiBVbmFsbG9jYXRlZCBUaW1lc2xvdHMgICAgICAgIHwNCiAg ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgLy8gICAgICAgICAgICAgICAgICAg ICAgICAgICAgLiAuIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8vDQogICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsgIA0KICAgICAgfCAgU2lnbmFsIFR5cGUgIHwgICAgICAgIE51 bWJlciBvZiBVbmFsbG9jYXRlZCBUaW1lc2xvdHMgICAgICAgIHwNCiAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoN CkkgdGhpbmsgYWxsIHRoZSBhYm92ZSBleHRlbnNpb25zIGFyZSBpbiBvcmRlciB0byBjYXJyeSBl bm91Z2ggaW5mb3JtYXRpb24gDQpmb3IgYmFuZHdpZHRoIGNvdW50aW5nLiBCdXQgdGhlcmUgc2hv dWxkIGJlIGEgbW9yZSBnZW5lcmFsIHNvbHV0aW9uIGZvciANClRETSBpbmNsdWRpbmcgU0RIIGFu ZCBPRFVrLg0KDQooMikgRm9sbHdvaW5nIGNvbW1lbnRzIGFyZSBhYm91dCANCmRyYWZ0LXpoYW5n LWNjYW1wLWdtcGxzLWc3MDktbG1wLWRpc2NvdmVyeS0wMi50eHQgLg0KQXMgYmlkaXJlY3Rpb25h bCBsaW5rcyB3aXRoIGRpZmZlcmVudCBJbnRlcmZhY2UgU3dpdGNoaW5nIENhcGFiaWxpdGllcyBh dCANCml0cyB0d28gZW5kcyBhcmUgYWxsb3dlZCwgZm9yIGEgYmlkaXJlY3Rpb25hbCBsaW5rIHRo ZSBub2RlIHVzZXMgaXRzIFRFRCANCnRvIGRldGVybWluZSB0aGUgSW50ZXJmYWNlIFN3aXRjaGlu ZyBDYXBhYmlsaXR5IERlc2NyaXB0b3Iocykgb2YgdGhlIA0KZmFyLWVuZCBvZiB0aGUgbGluay4g VGhlIG5vZGUgY2FuIGtub3cgdGhlIHRyaWJ1dGFyeSBzbG90IHNpemUgYW5kIHRoZSANCnN1cHBv cnRpbmcgTE8gT0RVIHNpZ25hbCB0eXBlIGluIHRoZSB0aGUgZmFyLWVuZCBvZiB0aGUgbGluay4g DQpUaGlzIHZpZXcgcG9pbnQgYWxzbyBpcyByZWZlcmVkIGluIA0KZHJhZnQtemhhbmctY2NhbXAt Z21wbHMtZzcwOS1sbXAtZGlzY292ZXJ5LTAyLnR4dCAoaS5lLiwgobFOb3RlIHRoYXQgTE8gDQpP RFUgdHlwZSBpbmZvcm1hdGlvbiBjYW4gYmUsIGluIHByaW5jaXBsZSwgZGlzY292ZXJlZCBieSBy b3V0aW5nLiBTaW5jZSBpbiANCmNlcnRhaW4gY2FzZSwgcm91dGluZyBpcyBub3QgcHJlc2VudCAo ZS5nLiBVTkkgY2FzZSkgd2UgbmVlZCB0byBleHRlbmQgDQpsaW5rIG1hbmFnZW1lbnQgcHJvdG9j b2wgY2FwYWJpbGl0aWVzIHRvIGNvdmVyIHRoaXMgYXNwZWN0LqGwKS4gDQpBY2NvcmRpbmcgdG8g Ry43MDkgQW1kIDMgKGkuZS4sICJFcXVpcG1lbnQgc3VwcG9ydGluZyBPRFRVay50cyBmb3IgT1BV MiBvciANCk9QVTMgbXVzdCBiZSBiYWNrd2FyZCBjb21wYXRpYmxlIHdpdGggZXF1aXBtZW50IHdo aWNoIHN1cHBvcnRzIG9ubHkgdGhlIA0KT0RUVWprLiBPRFRVay50cyBjYXBhYmxlIGVxdWlwbWVu dCB0cmFuc21pdHRpbmcgUFQ9MjEgd2hpY2ggcmVjZWl2ZXMgUFQ9MjAgDQpmcm9tIHRoZSBmYXIg ZW5kIHNoYWxsIHJldmVydCB0byBQVD0yMCBhbmQgb3BlcmF0ZSBpbiBPRFRVamsgb25seSBtb2Rl LiANClJlZmVyIHRvIEcuNzk4IGZvciB0aGUgc3BlY2lmaWNhdGlvbi4iDQopLCBmb3IgaW50ZXJ3 b3JraW5nIGJldHdlZW4gMUcyNSBhbmQgMkc1IGNhcGFibGUgZXF1aXBtZW50IHNob3VsIGJlICBh biANCmF1dG9tYXRpYyBhZGFwdGF0YWlvbi4gU28gdGhlcmUgaXMgbm8gbmVjZXNzYXJ5IGNvb3Jk aW5hdGlvbiBmb3IgdGhlIFRTIA0Kc2l6ZSBiZXR3ZWVuIHR3byBlbmRzIG9mIG9uZSBsaW5rIGlu IHRoZSBuZXR3b3JrLiBJbnRlcndvcmtpbmcgYmV0d2VlbiANClJGQzQzMjggYW5kIG5ldyBleHRl bnNpb24gc2hvdWwgYWxzbyBiZSBhbiBhdXRvbWF0aWMgYWRhcHRhdGFpb24uIA0KRG9lcyBpdCBt ZWFuIHRoZSBleHRlbnNpb24gZGVmaW5lZCBpbiB0aGUgZHJhZnQtemhhbmctZGlzY292ZXJ5IG9u bHkgYmUgDQp1c2VkIGluIHRoZSBVTkkgPyBDb3VsZCB5b3UgZ2l2ZSBhIHNjZW5hcmlvIHdoZXJl IGRpc2NvdmVyeSBpcyB1c2VkIGluIFVOSSANCj8NCg0KWGlodWEgRnUNClpURSBDb3Jwb3JhdGlv bg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogZnUueGlodWFAenRlLmNv bS5jbiANClRvOiB6aGFuZ2ZhdGFpQGh1YXdlaS5jb20gOyBDQ0FNUCANClNlbnQ6IFdlZG5lc2Rh eSwgT2N0b2JlciAyOCwgMjAwOSA0OjE4IFBNDQpTdWJqZWN0OiBSRTpbQ0NBTVBdIE9UTiBjb250 cm9sIGRyYWZ0cw0KDQoNCkhpIEZhdGFpIGFuZCBBbGwsIA0KDQpUaGVyZSBpcyBhbHNvIGFub3Ro ZXIgZHJhZnQgYWJvdXQgdGhlIE9EVWsgZXh0ZW5zaW9uIHdoaWNoIGhhcyBiZWVuIA0KcHJlc2Vu dGVkIGluIElFVEYgNzV0aCBtZWV0aW5nLiBJdCBoYXMgYmVlbiB1cGRhdGVkIHRvIA0KZHJhZnQt Y2VjY2FyZWxsaWZ1eGgtY2NhbXAtZ21wbHMtZXh0LWZvci1ldm9sLW90bi0wMS50eHQuIE5vdGU6 IFRoZSBuYW1lIA0Kb2YgdGhpcyB1cGRhdGVkIGRyYWZ0IHdpbGwgYmUgY2hhbmdlZCB0byANCmRy YWZ0LWZ1eGgtY2NhbXAtZ21wbHMtZXh0ZW5zaW9uLWZvci1ldm9sdXRpdmUtb3RuLTAxLnR4dCBh ZnRlciAwOSwgTm92LiANCndlJ2QgYXBwcmVjaWF0ZSB5b3VyIHJldmlldyBhbmQgY29tbWVudHMu IA0KDQpYaWh1YSBGdSANClpURSBDb3Jwb3JhdGlvbiANCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLSANCkZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQpGYXRhaSBaaGFuZyANClNlbnQ6IEZyaWRheSwg T2N0b2JlciAyMywgMjAwOSAxMTozMiBBTSANClRvOiBDQ0FNUCANClN1YmplY3Q6IFtDQ0FNUF0g T1ROIGNvbnRyb2wgZHJhZnRzIA0KICANCkhpIENDQU1QZXJzLCANCiAgDQpZb3Uga25vdyB0aGF0 IHRoZXJlIGFyZSBsb3RzIG9mIGludGVyZXN0cyBmcm9tIGJvdGggYSB0ZWNobmljYWwgYW5kIA0K b3JnYW5pemF0aW9uYWwgc3RhbmRwb2ludCAoZS5nLiwgSVRVLVQgU0cxNS9RMTIsUTE0LCBJRVRG IENDQU1QKSBvbiBPVE4gDQpjb250cm9sLCBzaW5jZSBkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1l dm9sdmluZy1nNzA5LTAwLnR4dCB3YXMgcHJlc2VudGVkIA0KaW4gSUVURiA3NXRoIG1lZXRpbmcu IA0KICANCllvdSBhbHNvIGtub3cgdGhhdCBbRy43MDkgVjNdIGluY2x1ZGluZyBPRFUwLCBPRFU0 LCBPRFVmbGV4Li4uIHdhcyANCmNvbnNlbnRlZCBieSBJVFUtVCBTRzE1IGluIHRoaXMgT2N0b2Jl ci4gIFRoZXJlZm9yZSwgaW4gb3JkZXIgdG8gY29udHJvbCANCmFuZCBtYW5hZ2UgdGhlIE9UTiBu ZXR3b3JrcyBlZmZpY2llbnRseSwgT1ROIGNvbnRyb2wgaXMgcmVhbGx5IGltcG9ydGFudCANCmZv ciB0aGUgaW5kdXN0cnkuIA0KICANClVwIHRvIG5vdywgd2UgaGF2ZSBmaXZlIGRyYWZ0cyBhYm91 dCBPVE4gY29udHJvbDogDQooMSkgZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdv cmstMDAudHh0IA0KKDIpIGRyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWV2b2x2aW5nLWc3MDktMDMu dHh0IA0KKDMpIGRyYWZ0LWNlY2NhcmVsbGktY2NhbXAtZ21wbHMtb3NwZi1nNzA5LTAwLnR4dCAN Cig0KSBkcmFmdC1jZWNjYXJlbGxpLWNjYW1wLWdtcGxzLWc3MDktbG1wLXRlc3QtMDEudHh0IA0K KDUpIGRyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWc3MDktbG1wLWRpc2NvdmVyeS0wMi50eHQgDQog IA0KVG8gcHJvbW90ZSBiZXR0ZXIgdW5kZXJzdGFuZGluZyBvciB0aGUgZGlzY3Vzc2lvbnMgaW4g SGlyb3NoaW1hIG1lZXRpbmcsIA0Kd2UnZCBhcHByZWNpYXRlIHlvdXIgcmV2aWV3IGFuZCBjb21t ZW50cy4gDQogIA0KICANClRoYW5rcyANCiAgDQpBdXRob3JzIG9mIHRoZXNlIGRyYWZ0cyANCiAg DQogX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQpDQ0FN UCBtYWlsaW5nIGxpc3QgDQpDQ0FNUEBpZXRmLm9yZyANCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2NhbXANCg0K --=_alternative 001E93AD48257660_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEFsbCw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJGQzM2MzAgZGVmaW5lcyB0aGUg TWF4aW11bSBCYW5kd2lkdGgNCmFuZCAmbmJzcDtVbnJlc2VydmVkIEJhbmR3aWR0aC4gUkZDNDIw MiBhbmQgUkZDNDIwMyBkZWZpbmUgSW50ZXJmYWNlIFN3aXRjaGluZw0KQ2FwYWJpbGl0eSBEZXNj cmlwdG9yIChJU0NEKSBpbmNsdWRpbmcgTWF4IExTUCBCYW5kd2lkdGggYXQgcHJpb3JpdHkgcA0K YW5kIE1pbmltdW0gTFNQIEJhbmR3aWR0aCBpbiB0aGUgU3dpdGNoaW5nIENhcGFiaWxpdHkgc3Bl Y2lmaWMgaW5mb3JtYXRpb24NCmZpZWxkLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+KDEpIEZvbGxvd2luZyBjb21tZW50cyBhcmUgYWJvdXQgZHJhZnQt Y2VjY2FyZWxsaS1jY2FtcC1nbXBscy1vc3BmLWc3MDktMDAudHh0LjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U3dpdGNoaW5nIENhcGFiaWxpdHktc3BlY2lmaWMg aW5mb3JtYXRpb24NCmlzIGluZmVyZWQgYnkgYSBuZXcgU3dpdGNoaW5nIENhcGFiaWxpdHkgKGku ZS4sICZxdW90OzxpPkV2b2x2ZWQgT1ROPC9pPiZxdW90Ow0KKSBkZWZpbmVkIGluIGRyYWZ0LWNl Y2NhcmVsbGktY2NhbXAtZ21wbHMtb3NwZi1nNzA5LTAwLnR4dC4gVGhpcyBtZXRob2QNCmxhY2tz IG9mIGdlbmVyYWwgcHVycG9zZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkNhbiB3ZSB1c2UgdGhlIGN1cnJlbnQgZXh0ZW5zaW9ucyBkZWZpbmVkDQppbiBSRkMz NjMwIGFuZCBSRkM0MjAyIHRvIG1lZXQgdGhlIHJlcXVpcmVtZW50IHdoaWNoIGlzIHBvaW50ZWQg b3V0IGluDQp0aGVzZSBkcmFmdHMgPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+T25lIG9wdGlvbiBpcyB0byBhZHZlcnRpc2UgbXVsdGlwbGUNCklTQ0Qgc3ViLVRM VnMgd2l0aGluIGEgc2luZ2xlIExpbmsgVExWIGZvciB0aGUgbGluay4gQnV0IGluZm9ybWF0aW9u IGlzDQpyZXBlYXRlZCBmb3IgZWFjaCBMTyBPRFUgc2lnbmFsIHR5cGUuIEFzbG8gdGhlcmUgaXMg bm90IGVub3VnaCBpbmZvcm1hdGlvbg0KZm9yIGNvbXBvc2VkIHNpZ25hbCBjb21wdXRhdGlvbi48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjEuIEZvciBleGFtcGxl LCBpbiBvcmRlciB0byByZXByZXNlbnQNCm9uZSBpbnRlcmZhY2UgcG9ydCBvZiB0aGUgT0RVNC9P VFU0ICZuYnNwO1RFIGxpbmsgd2l0aCAyLjVHIFRTIHdoaWNoIG9ubHkNCnN1cHBvcnRzIE9EVTMg b3IgT0RVMiwgdGhlcmUgY2FuIGJlIHRocmVlIElTQ0RzLjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIHNpemUgb2YgdHJpYnV0YXJ5IHNsb3QgY2FuIGJlIGlu ZmVyZWQNCmJ5IHRoZSBNaW4gTFNQIEJhbmR3aWR0aCBpbiB0aGUgSVNDRCAxLiBMTyBPRFUgc2ln bmFsIHR5cGVzIHN1cHBvcnRlZCBieQ0KdGhlIGludGVyZmFjZSBwb3J0IGNhbiBiZSBpbmZlcmVk IGJ5IHRoZSBJU0NEIDIgYW5kIElTQ0QgMy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7PGI+TWF4aW11bSBCYW5kd2lkdGg8L2I+ DQo9IEJhbmR3aWR0aCBvZiBPRFU0ICgyMzkvMjI3IKHBIDk5IDUzMiA4MDAga2JpdC9zICsvLSAy MCBwcG0pL09UVTQgKGUuZw0KMjU1LzIyNyChwSA5OSA1MzIgODAwIGtiaXQvcyArLy0yMCBwcG0p PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 ICZuYnNwO0ludGVyZmFjZSBTd2l0Y2hpbmcNCkNhcGFiaWxpdHkgRGVzY3JpcHRvciAxOjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0ludGVyZmFjZQ0KU3dpdGNoaW5nIENhcGFiaWxpdHkgPSBURE08L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtFbmNvZGluZw0KPSBHLjcwOSBPRFVrIChEaWdpdGFsIFBhdGgpPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7TWluDQpMU1AgQmFuZHdpZHRoID0gPGI+Mi41RyBUUzwvYj48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtNYXgNCkxTUCBCYW5kd2lkdGhbcF0gPSA8Yj5PRFU0L09UVTQ8L2I+ LCBmb3IgYWxsIHA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDssPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwO0ludGVyZmFjZSBTd2l0Y2hp bmcNCkNhcGFiaWxpdHkgRGVzY3JpcHRvciAyOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ludGVyZmFj ZQ0KU3dpdGNoaW5nIENhcGFiaWxpdHkgPSBURE08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtFbmNvZGlu Zw0KPSBHLjcwOSBPRFVrIChEaWdpdGFsIFBhdGgpPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TWluDQpM U1AgQmFuZHdpZHRoID0gPGI+T0RVMjwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtNYXgNCkxTUCBC YW5kd2lkdGhbcF0gPSA8Yj5PRFUyIDwvYj4sIGZvciBhbGwgcDwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO0ludGVyZmFjZQ0KU3dpdGNoaW5nIENhcGFiaWxpdHkgRGVzY3JpcHRvciAzOjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0ludGVyZmFjZQ0KU3dpdGNoaW5nIENhcGFiaWxpdHkgPSBURE08L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtFbmNvZGluZw0KPSBHLjcwOSBPRFVrIChEaWdpdGFsIFBhdGgpPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7TWluDQpMU1AgQmFuZHdpZHRoID0gPGI+T0RVMzwvYj48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtNYXgNCkxTUCBCYW5kd2lkdGhbcF0gPSA8Yj5PRFUzIDwvYj4sIGZvciBh bGwgcDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Mi4g QW5vdGhlciBleGFtcGxlLCBpbiBvcmRlciB0byByZXByZXNlbnQNCm9uZSBpbnRlcmZhY2UgcG9y dCBvZiB0aGUgT0RVMy9PVFUzIFRFIGxpbmsgbGluayB3aXRoIDEuMjVHIFRTIHdoaWNoIG9ubHkN CnN1cHBvcnRzIE9EVTIsIHRoZXJlIGNhbiBiZSB0d28gSVNDRHMuPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgc2l6ZSBvZiB0cmlidXRhcnkgc2xvdCBjYW4g YmUgaW5mZXJlZA0KYnkgdGhlIE1pbiBMU1AgQmFuZHdpZHRoIGluIHRoZSBJU0NEIDEuIExPIE9E VSBzaWduYWwgdHlwZXMgc3VwcG9ydGVkIGJ5DQp0aGUgaW50ZXJmYWNlIHBvcnQgY2FuIGJlIGlu ZmVyZWQgYnkgdGhlIElTQ0QgMiBhbmQgSVNDRCAzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDs8Yj4gTWF4aW11bSBCYW5kd2lk dGg8L2I+DQo9IEJhbmR3aWR0aCBvZiBPRFUzICgyMzkvMjM2IKHBIDM5IDgxMyAxMjAga2JpdC9z ICsvLSAyMCBwcG0pL09UVTMgKGUuZw0KMjU1LzIzNiChwSAzOSA4MTMgMTIwIGtiaXQvcyArLy0y MCBwcG0pPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyBJbnRlcmZhY2UgU3dpdGNoaW5nDQpDYXBhYmlsaXR5IERlc2NyaXB0b3Ig MTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbnRlcmZhY2UNClN3aXRjaGluZyBDYXBhYmlsaXR5ID0g VERNPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RW5jb2RpbmcNCj0gRy43MDkgT0RVayAoRGlnaXRhbCBQ YXRoKTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO01pbg0KTFNQIEJhbmR3aWR0aCA9IDxiPjEuMjVHIFRT PC9iPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO01heA0KTFNQIEJhbmR3aWR0aFtwXSA9IDxiPk9EVTMv T1RVMzwvYj4sIGZvciBhbGwgcDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSW50ZXJmYWNlIFN3aXRjaGluZw0KQ2Fw YWJpbGl0eSBEZXNjcmlwdG9yIDI6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW50ZXJmYWNlDQpTd2l0 Y2hpbmcgQ2FwYWJpbGl0eSA9IFRETTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0VuY29kaW5nDQo9IEcu NzA5IE9EVWsgKERpZ2l0YWwgUGF0aCk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtNaW4NCkxTUCBCYW5k d2lkdGggPSA8Yj5PRFUyPC9iPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO01heA0KTFNQIEJhbmR3aWR0 aFtwXSA9IDxiPk9EVTIgPC9iPiwgZm9yIGFsbCBwPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Bbm90aGVyIG9wdGlvbiBpcyBkZWZpbmVkIGluIE9JRiAm bmJzcDtFLU5OSQ0KMi4wLiBJdCBkZWZpbmVkIHRoZSBmb2xsb3dpbmcgZXh0ZW5zaW9uIGZvciBT REggYW5kIE9EVWsuIEJ1dCBJIHRoaWsgdGhlcmUNCmlzIG5vdCBlbm91Z2ggaW5mb3JtYXRpb24g Zm9yIHRoZSBwcmVlbXB0IGNvbXB1dGF0aW9uIGRlZmluZWQgaW4gW1JGQzMyMDldLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzAgMSAyIDMNCjQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwO1R5cGUgKEVYUCkgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7TGVuZ3RoID0gNCAr IG4qNCAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyB8IFN3 aXRjaGluZyBDYXANCnwgJm5ic3A7IEVuY29kaW5nICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUmVzZXJ2ZWQNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7fDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDtTaWdu YWwNClR5cGUgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtOdW1iZXIgb2YgVW5h bGxvY2F0ZWQgVGltZXNsb3RzDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJz cDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO1NpZ25hbA0KVHlwZSAmbmJzcDt8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO051bWJlciBvZiBVbmFsbG9jYXRlZCBUaW1lc2xvdHMNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3w8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAvLyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsuIC4gLiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvLzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KJm5i c3A7ICZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4m bmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwO1NpZ25hbA0KVHlwZSAmbmJzcDt8ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO051bWJlciBvZiBVbmFsbG9jYXRlZCBUaW1lc2xvdHMNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSB0aGluayBhbGwgdGhlIGFib3ZlIGV4 dGVuc2lvbnMgYXJlDQppbiBvcmRlciB0byBjYXJyeSBlbm91Z2ggaW5mb3JtYXRpb24gZm9yIGJh bmR3aWR0aCBjb3VudGluZy4gQnV0IHRoZXJlDQpzaG91bGQgYmUgYSBtb3JlIGdlbmVyYWwgc29s dXRpb24gZm9yIFRETSBpbmNsdWRpbmcgU0RIIGFuZCBPRFVrLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+KDIpIEZvbGx3b2luZyBjb21tZW50cyBhcmUg YWJvdXQgZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZzcwOS1sbXAtZGlzY292ZXJ5LTAyLnR4dA0K LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXMgYmlkaXJlY3Rp b25hbCBsaW5rcyB3aXRoIGRpZmZlcmVudA0KSW50ZXJmYWNlIFN3aXRjaGluZyBDYXBhYmlsaXRp ZXMgYXQgaXRzIHR3byBlbmRzIGFyZSBhbGxvd2VkLCBmb3IgYSBiaWRpcmVjdGlvbmFsDQpsaW5r IHRoZSBub2RlIHVzZXMgaXRzIFRFRCB0byBkZXRlcm1pbmUgdGhlIEludGVyZmFjZSBTd2l0Y2hp bmcgQ2FwYWJpbGl0eQ0KRGVzY3JpcHRvcihzKSBvZiB0aGUgZmFyLWVuZCBvZiB0aGUgbGluay4g VGhlIG5vZGUgY2FuIGtub3cgdGhlIHRyaWJ1dGFyeQ0Kc2xvdCBzaXplIGFuZCB0aGUgc3VwcG9y dGluZyBMTyBPRFUgc2lnbmFsIHR5cGUgaW4gdGhlIHRoZSBmYXItZW5kIG9mIHRoZQ0KbGluay4g PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGlzIHZpZXcgcG9p bnQgYWxzbyBpcyByZWZlcmVkIGluIGRyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWc3MDktbG1wLWRp c2NvdmVyeS0wMi50eHQNCihpLmUuLCA8aT6hsU5vdGUgdGhhdCBMTyBPRFUgdHlwZSBpbmZvcm1h dGlvbiBjYW4gYmUsIGluIHByaW5jaXBsZSwgZGlzY292ZXJlZA0KYnkgcm91dGluZy4gU2luY2Ug aW4gY2VydGFpbiBjYXNlLCByb3V0aW5nIGlzIG5vdCBwcmVzZW50IChlLmcuIFVOSSBjYXNlKQ0K d2UgbmVlZCB0byBleHRlbmQgbGluayBtYW5hZ2VtZW50IHByb3RvY29sIGNhcGFiaWxpdGllcyB0 byBjb3ZlciB0aGlzIGFzcGVjdC6hsDwvaT4pLg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5BY2NvcmRpbmcgdG8gRy43MDkgQW1kIDMgKGkuZS4sIDxpPiZxdW90 O0VxdWlwbWVudA0Kc3VwcG9ydGluZyBPRFRVay50cyBmb3IgT1BVMiBvciBPUFUzIG11c3QgYmUg YmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIGVxdWlwbWVudA0Kd2hpY2ggc3VwcG9ydHMgb25seSB0 aGUgT0RUVWprLiBPRFRVay50cyBjYXBhYmxlIGVxdWlwbWVudCB0cmFuc21pdHRpbmcNClBUPTIx IHdoaWNoIHJlY2VpdmVzIFBUPTIwIGZyb20gdGhlIGZhciBlbmQgc2hhbGwgcmV2ZXJ0IHRvIFBU PTIwIGFuZCBvcGVyYXRlDQppbiBPRFRVamsgb25seSBtb2RlLiBSZWZlciB0byBHLjc5OCBmb3Ig dGhlIHNwZWNpZmljYXRpb24uJnF1b3Q7PC9pPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+KSwgZm9yIGludGVyd29ya2luZyBiZXR3ZWVuIDFHMjUgYW5kDQoyRzUg Y2FwYWJsZSBlcXVpcG1lbnQgc2hvdWwgYmUgJm5ic3A7YW4gYXV0b21hdGljIGFkYXB0YXRhaW9u LiBTbyB0aGVyZQ0KaXMgbm8gbmVjZXNzYXJ5IGNvb3JkaW5hdGlvbiBmb3IgdGhlIFRTIHNpemUg YmV0d2VlbiB0d28gZW5kcyBvZiBvbmUgbGluaw0KaW4gdGhlIG5ldHdvcmsuIEludGVyd29ya2lu ZyBiZXR3ZWVuIFJGQzQzMjggYW5kIG5ldyBleHRlbnNpb24gc2hvdWwgYWxzbw0KYmUgYW4gYXV0 b21hdGljIGFkYXB0YXRhaW9uLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkRvZXMgaXQgbWVhbiB0aGUgZXh0ZW5zaW9uIGRlZmluZWQgaW4NCnRoZSBkcmFmdC16 aGFuZy1kaXNjb3Zlcnkgb25seSBiZSB1c2VkIGluIHRoZSBVTkkgPyBDb3VsZCB5b3UgZ2l2ZSBh IHNjZW5hcmlvDQp3aGVyZSBkaXNjb3ZlcnkgaXMgdXNlZCBpbiBVTkkgPzwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+WGlodWEgRnU8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlpURSBDb3Jwb3JhdGlvbjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTM+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zPjxiPkZyb206PC9iPiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZnUu eGlodWFAenRlLmNvbS5jbj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5mdS54aWh1YUB6dGUu Y29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pg0KPGJyPjxmb250IHNp emU9Mz48Yj5Ubzo8L2I+IDwvZm9udD48YSBocmVmPW1haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5j b20+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+emhhbmdmYXRhaUBodWF3ZWkuY29tPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0zPg0KOyA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86Y2NhbXBAaWV0 Zi5vcmc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+Q0NBTVA8L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTM+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjxiPlNlbnQ6PC9iPiBXZWRuZXNk YXksIE9jdG9iZXIgMjgsIDIwMDkgNDoxOCBQTTwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+PGI+ U3ViamVjdDo8L2I+IFJFOltDQ0FNUF0gT1ROIGNvbnRyb2wgZHJhZnRzPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpIaSBGYXRhaSBhbmQgQWxs LDwvZm9udD48Zm9udCBzaXplPTM+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+PGJyPg0KVGhlcmUgaXMgYWxzbyBhbm90aGVyIGRyYWZ0IGFib3V0IHRoZSBPRFVr IGV4dGVuc2lvbiB3aGljaCBoYXMgYmVlbiBwcmVzZW50ZWQNCmluIElFVEYgNzV0aCBtZWV0aW5n LiBJdCBoYXMgYmVlbiB1cGRhdGVkIHRvIDwvZm9udD48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaWQvZHJhZnQtY2VjY2FyZWxsaWZ1eGgtY2NhbXAtZ21wbHMtZXh0LWZvci1ldm9sLW90 bi0wMS50eHQiPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1PmRyYWZ0LWNlY2NhcmVsbGlmdXho LWNjYW1wLWdtcGxzLWV4dC1mb3ItZXZvbC1vdG4tMDEudHh0PC91PjwvZm9udD48L2E+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPi4NCk5vdGU6IFRoZSBuYW1lIG9mIHRoaXMgdXBkYXRl ZCBkcmFmdCB3aWxsIGJlIGNoYW5nZWQgdG8gZHJhZnQtZnV4aC1jY2FtcC1nbXBscy1leHRlbnNp b24tZm9yLWV2b2x1dGl2ZS1vdG4tMDEudHh0DQphZnRlciAwOSwgTm92LjwvZm9udD48Zm9udCBz aXplPTM+IDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0Kd2UnZCBh cHByZWNpYXRlIHlvdXIgcmV2aWV3IGFuZCBjb21tZW50cy48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClhpaHVhIEZ1 PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQpaVEUgQ29ycG9yYXRpb248L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8YnI+DQot LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+PGI+PGJyPg0KRnJvbTwvYj46IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSA8Yj5Pbg0KQmVoYWxmIE9mPC9iPiBGYXRhaSBaaGFu ZzwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGI+PGJyPg0KU2VudDwvYj46IEZyaWRheSwgT2N0b2JlciAyMywgMjAwOSAxMTozMiBBTTwv Zm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ PGI+PGJyPg0KVG88L2I+OiBDQ0FNUDwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGI+PGJyPg0KU3ViamVjdDwvYj46IFtDQ0FNUF0gT1RO IGNvbnRyb2wgZHJhZnRzPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhpIENDQU1QZXJzLDwvZm9udD48 Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K IDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQpZb3Uga25vdyB0aGF0IHRoZXJlIGFyZSBsb3RzIG9mIGludGVyZXN0cyBm cm9tIGJvdGggYSB0ZWNobmljYWwgYW5kIG9yZ2FuaXphdGlvbmFsDQpzdGFuZHBvaW50IChlLmcu LCBJVFUtVCBTRzE1L1ExMixRMTQsIElFVEYgQ0NBTVApIG9uIE9UTiBjb250cm9sLCBzaW5jZQ0K ZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZXZvbHZpbmctZzcwOS0wMC50eHQgd2FzIHByZXNlbnRl ZCBpbiBJRVRGIDc1dGgNCm1lZXRpbmcuPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9Mz4mbmJz cDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCllvdSBhbHNvIGtu b3cgdGhhdCBbRy43MDkgVjNdIGluY2x1ZGluZyBPRFUwLCBPRFU0LCBPRFVmbGV4Li4uIHdhcyBj b25zZW50ZWQNCmJ5IElUVS1UIFNHMTUgaW4gdGhpcyBPY3RvYmVyLiAmbmJzcDtUaGVyZWZvcmUs IGluIG9yZGVyIHRvIGNvbnRyb2wgYW5kDQptYW5hZ2UgdGhlIE9UTiBuZXR3b3JrcyBlZmZpY2ll bnRseSwgT1ROIGNvbnRyb2wgaXMgcmVhbGx5IGltcG9ydGFudCBmb3INCnRoZSBpbmR1c3RyeS48 L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KVXAgdG8gbm93LCB3ZSBoYXZlIGZpdmUgZHJhZnRzIGFib3V0 IE9UTiBjb250cm9sOjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KKDEpPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh Y2U9InNhbnMtc2VyaWYiPjx1PiBkcmFmdC16aGFuZy1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29y ay0wMC50eHQNCjwvdT48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N CigyKSA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+ ZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZXZvbHZpbmctZzcwOS0wMy50eHQ8L3U+PC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCigzKSA8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+ZHJhZnQtY2VjY2FyZWxsaS1jY2Ft cC1nbXBscy1vc3BmLWc3MDktMDAudHh0DQo8L3U+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj48YnI+DQooNCkgPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 InNhbnMtc2VyaWYiPjx1PmRyYWZ0LWNlY2NhcmVsbGktY2NhbXAtZ21wbHMtZzcwOS1sbXAtdGVz dC0wMTwvdT48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjx1Pi50eHQNCjwv dT48YnI+DQooNSkgPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjx1PmRyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWc3MDktbG1wLWRpc2NvdmVyeS0wMi50eHQ8 L3U+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KVG8gcHJvbW90ZSBiZXR0ZXIgdW5kZXJzdGFuZGluZyBvciB0aGUgZGlzY3Vzc2lvbnMg aW4gSGlyb3NoaW1hIG1lZXRpbmcsDQp3ZSdkIGFwcHJlY2lhdGUgeW91ciByZXZpZXcgYW5kIGNv bW1lbnRzLjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9Mz4mbmJzcDs8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClRoYW5rczwvZm9udD48 Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K IDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQpBdXRob3JzIG9mIHRoZXNlIGRyYWZ0czwvZm9udD48Zm9udCBzaXplPTM+ IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KIDwvZm9udD48Zm9u dCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQogX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2ZvbnQ+ PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N CkNDQU1QIG1haWxpbmcgbGlzdDwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KQ0NBTVBAaWV0Zi5vcmc8L2ZvbnQ+PGZvbnQgc2l6 ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjx1Pjxicj4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8L3U+PC9mb250Pg0KPGJyPg0K --=_alternative 001E93AD48257660_=--