From lberger@labn.net Tue Jan 5 15:13:14 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2A933A681A for ; Tue, 5 Jan 2010 15:13:14 -0800 (PST) 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 vRsqNY7Znrjf for ; Tue, 5 Jan 2010 15:13:14 -0800 (PST) Received: from outbound-mail-153.bluehost.com (outbound-mail-153.bluehost.com [67.222.39.33]) by core3.amsl.com (Postfix) with SMTP id 79ED43A659C for ; Tue, 5 Jan 2010 15:13:14 -0800 (PST) Received: (qmail 7805 invoked by uid 0); 5 Jan 2010 23:06:33 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy5.bluehost.com with SMTP; 5 Jan 2010 23:06: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:CC:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=UwJlRvra4gS8BdJLjW8W7/we4xysA38BsWY1IuSUXAW3wqO0P3jCzUDi1G/HiTCSmkYHCrAGgqQncMnwq4d6ecXhGSy4M1nLAGzvVCWM28c/UXbiQsiSk8qutS8NYxv3; 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 1NSITx-00034k-JX; Tue, 05 Jan 2010 16:06:33 -0700 Message-ID: <4B43C605.6040503@labn.net> Date: Tue, 05 Jan 2010 18:06:45 -0500 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; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , iesg-secretary@ietf.org Subject: [CCAMP] Please publish draft-ietf-ccamp-gmpls-mln-extensions-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: Tue, 05 Jan 2010 23:13:14 -0000 Proto-write-up for: draft-ietf-ccamp-gmpls-mln-extensions-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. >(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. >(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. >(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. There are two references that are drafts: [GMPLS-RR] Berger, L., Papadimitriou, D., and JP. Vasseur, "PathErr Message Triggered MPLS and GMPLS LSP Reroute", draft-ietf-mpls-gmpls-lsp-reroute, Work in progress. [HIER-BIS] Shiomoto, K., and Farrel, A., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", draft-ietf ccamp-lsp-hierarchy-bis, Work in progress. The first draft is in the RFC editor's queue and the second is in the IESG publication process. > If such normative references exist, what is the > strategy for their completion? Both documents are essential complete and are in the publication process. > 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? The IANA section looks good. >(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 extends GMPLS routing and signaling to support the operation of GMPLS Multi-Layer/Multi-Region Networks. A network comprised of multiple switching types (e.g. PSC and TDM) controlled by a single GMPLS control plane instance is called a Multi-Region Network (MRN). A network comprising transport nodes participating in different data plane switching layers controlled by a single GMPLS control plane instance is called a Multi-Layer Network (MLN). This document defines GMPLS RSVP, OSPF and IS-IS to cover GMPLS MLN/MRN requirements. > 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 much attention and discussion in its early revisions. The document has been largely stable for quite some time, mainly needing revisions as part of the publication process. > 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 the portions of the extensions are now being used as part of the GMPLS tool set and are (at least) expected to implemented in those contexts. > 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 root@core3.amsl.com Fri Jan 8 03:15:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3A8853A6957; Fri, 8 Jan 2010 03:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100108111502.3A8853A6957@core3.amsl.com> Date: Fri, 8 Jan 2010 03:15:02 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-pc-spc-rsvpte-ext-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, 08 Jan 2010 11: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 : RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network. Author(s) : D. Caviglia, et al. Filename : draft-ietf-ccamp-pc-spc-rsvpte-ext-05.txt Pages : 22 Date : 2010-01-08 In a transport network scenario, where Data Plane connections are controlled either by a Generalized Multi-Protocol Label Switching (GMPLS) Control Plane (Soft Permanent Connections - SPC) or by a Management System (Permanent Connections - PC) may independently coexist, the ability of transforming an existing PC into a SPC and vice versa - without actually affecting Data Plane traffic being carried over it - is a requirement. The requirements for the conversion between permanent connections and switched connections in a GMPLS Network are defined in [RFC5493]. This memo describes an extension to GMPLS RSVP-TE signaling that enables the transfer of connection ownership between the Management and the Control Planes. Such a transfer is referred to as a Handover. This document defines all Handover related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the handover procedures must never impact an already established Data plane. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 12, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-spc-rsvpte-ext-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-pc-spc-rsvpte-ext-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-08031215.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jan 11 10:30:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5694D3A68EA; Mon, 11 Jan 2010 10:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100111183002.5694D3A68EA@core3.amsl.com> Date: Mon, 11 Jan 2010 10:30:02 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-vcat-lcas-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2010 18: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 : draft-ietf-ccamp-gmpls-vcat-lcas-09.txt Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-gmpls-vcat-lcas-09.txt Pages : 21 Date : 2010-01-11 This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. 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-gmpls-vcat-lcas-09.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-vcat-lcas-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-11102021.I-D@ietf.org> --NextPart-- From lberger@labn.net Wed Jan 13 07:40:51 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB9B33A67A7 for ; Wed, 13 Jan 2010 07:40:51 -0800 (PST) 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 ah9IFcXp4sQB for ; Wed, 13 Jan 2010 07:40:50 -0800 (PST) Received: from outbound-mail-30.bluehost.com (outbound-mail-30.bluehost.com [69.89.17.212]) by core3.amsl.com (Postfix) with SMTP id B7FB63A681D for ; Wed, 13 Jan 2010 07:40:50 -0800 (PST) Received: (qmail 9601 invoked by uid 0); 13 Jan 2010 15:40:47 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy2.bluehost.com with SMTP; 13 Jan 2010 15:40:47 -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=CMfi78s2O39x4lCGvmrrDOpm2pr+XUwAb5xDty/Mut6lX++ctXGROwtY9kVfkIdZi+CxlVRH3m7b9+KHbLym1xZWz+UusVV2LOeb4bbCwc2A9aF45k10k50+EzYAev/Q; 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 1NV5Kx-0005Lt-IL; Wed, 13 Jan 2010 08:40:47 -0700 Message-ID: <4B4DE99C.7010005@labn.net> Date: Wed, 13 Jan 2010 10:41:16 -0500 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-vcat-lcas@tools.ietf.org References: <20100111183002.5694D3A68EA@core3.amsl.com> In-Reply-To: <20100111183002.5694D3A68EA@core3.amsl.com> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-vcat-lcas-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 15:40:51 -0000 Authors, Thank you for the post-LC revision. Please let the WG know how the last call comments were resolved. Lou On 1/11/2010 1:30 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > > Title : draft-ietf-ccamp-gmpls-vcat-lcas-09.txt > Author(s) : G. Bernstein, et al. > Filename : draft-ietf-ccamp-gmpls-vcat-lcas-09.txt > Pages : 21 > Date : 2010-01-11 > > This document describes requirements for, and use of, the Generalized > Multi-Protocol Label Switching (GMPLS) control plane in conjunction > with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing > mechanism and its companion Link Capacity Adjustment Scheme (LCAS) > which can be used for hitless dynamic resizing of the inverse > multiplex group. These techniques apply to Optical Transport Network > (OTN), Synchronous Optical Network (SONET), Synchronous Digital > Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. > > 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-gmpls-vcat-lcas-09.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > ------------------------------------------------------------------------ > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From gregb@grotto-networking.com Wed Jan 13 08:07:18 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F60B3A69FA for ; Wed, 13 Jan 2010 08:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZblRgyG7LTqC for ; Wed, 13 Jan 2010 08:07:17 -0800 (PST) Received: from mail16c40.carrierzone.com (mail16c40.carrierzone.com [209.235.156.156]) by core3.amsl.com (Postfix) with ESMTP id D8C6F3A680F for ; Wed, 13 Jan 2010 08:07:16 -0800 (PST) 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]) (authenticated bits=0) by mail16c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id o0DG7DgX011978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Jan 2010 11:07:18 -0500 Message-ID: <4B4DEFAF.1090702@grotto-networking.com> Date: Wed, 13 Jan 2010 08:07:11 -0800 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ccamp@ietf.org References: <20100111183002.5694D3A68EA@core3.amsl.com> <4B4DE99C.7010005@labn.net> In-Reply-To: <4B4DE99C.7010005@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-vcat-lcas-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 16:07:18 -0000 Hello CCAMP the LC comments were resolved as follows: (a) All suggestions for corrections to grammar and punctuation were implemented. (b) Adopted new suggested wording for section 4 clarifying that this section is informational . (c) Added conceptual clarification to section 5, to differentiate concepts from implementation considerations. Added explanatory figure 1. (d) Clarified the VCAT TLV in section 5.2. (e) Clarified and elaborated on the procedures of section 5.3 (f) Elaborated on the error conditions/codes of section 6. (g) Edited and updated the IANA considerations (section 7). Best Regards Greg Lou Berger wrote: > Authors, > Thank you for the post-LC revision. Please let the WG know how > the last call comments were resolved. > > Lou > > On 1/11/2010 1:30 PM, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Common Control and Measurement Plane >> Working Group of the IETF. >> >> >> Title : draft-ietf-ccamp-gmpls-vcat-lcas-09.txt >> Author(s) : G. Bernstein, et al. >> Filename : draft-ietf-ccamp-gmpls-vcat-lcas-09.txt >> Pages : 21 >> Date : 2010-01-11 >> >> This document describes requirements for, and use of, the Generalized >> Multi-Protocol Label Switching (GMPLS) control plane in conjunction >> with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing >> mechanism and its companion Link Capacity Adjustment Scheme (LCAS) >> which can be used for hitless dynamic resizing of the inverse >> multiplex group. These techniques apply to Optical Transport Network >> (OTN), Synchronous Optical Network (SONET), Synchronous Digital >> Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. >> >> 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-gmpls-vcat-lcas-09.txt >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From root@core3.amsl.com Wed Jan 13 08:15:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 214E13A6810; Wed, 13 Jan 2010 08:15:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100113161502.214E13A6810@core3.amsl.com> Date: Wed, 13 Jan 2010 08:15:02 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-pc-spc-rsvpte-ext-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 16: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 : RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network. Author(s) : D. Caviglia, et al. Filename : draft-ietf-ccamp-pc-spc-rsvpte-ext-06.txt Pages : 22 Date : 2010-01-13 In a transport network scenario, where Data Plane connections are controlled either by a Generalized Multi-Protocol Label Switching (GMPLS) Control Plane (Soft Permanent Connections - SPC) or by a Management System (Permanent Connections - PC) may independently coexist, the ability of transforming an existing PC into a SPC and vice versa - without actually affecting Data Plane traffic being carried over it - is a requirement. The requirements for the conversion between permanent connections and switched connections in a GMPLS Network are defined in [RFC5493]. This memo describes an extension to GMPLS RSVP-TE signaling that enables the transfer of connection ownership between the Management and the Control Planes. Such a transfer is referred to as a Handover. This document defines all Handover related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the handover procedures must never impact an already established Data plane. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 17, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-spc-rsvpte-ext-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-pc-spc-rsvpte-ext-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-13080606.I-D@ietf.org> --NextPart-- From loa@pi.nu Wed Jan 13 09:01:14 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56F8D3A67E2; Wed, 13 Jan 2010 09:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 30JHTxFmRKMT; Wed, 13 Jan 2010 09:01:13 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 0C8503A677D; Wed, 13 Jan 2010 09:01:12 -0800 (PST) Received: from [192.36.158.110] (wdhcp-158-110.verkstad.net [192.36.158.110]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 0D08DD403E; Wed, 13 Jan 2010 18:01:07 +0100 (CET) Message-ID: <4B4DFC51.8050301@pi.nu> Date: Wed, 13 Jan 2010 18:01:05 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: mpls-tp@ietf.org, mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 17:01:14 -0000 All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 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. Please note that it is a conscious decision by the wg chair to poll the linear-protection document prior to the ring-protection document, since we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa -- From nurit.sprecher@nsn.com Wed Jan 13 09:06:37 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2782B3A680B; Wed, 13 Jan 2010 09:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7bvDEmzn3ZV; Wed, 13 Jan 2010 09:06:36 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id DDA9D3A67EE; Wed, 13 Jan 2010 09:06:35 -0800 (PST) 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 o0DH6V0e019326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jan 2010 18:06:31 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o0DH6VEp027256; Wed, 13 Jan 2010 18:06:31 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 18:06:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jan 2010 18:03:13 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326401B968CB@DEMUEXC014.nsn-intra.net> In-Reply-To: <4B4DFC51.8050301@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document Thread-Index: AcqUcgT/CqHWXbshQuCgRQHJYMzFdAAACAGg References: <4B4DFC51.8050301@pi.nu> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Loa Andersson" , , , , X-OriginalArrivalTime: 13 Jan 2010 17:06:31.0051 (UTC) FILETIME=[C0838DB0:01CA9472] Subject: Re: [CCAMP] [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 17:06:37 -0000 Yes/Support. -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Wednesday, January 13, 2010 7:01 PM To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 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. Please note that it is a conscious decision by the wg chair to poll the linear-protection document prior to the ring-protection document, since we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa --=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From annamaria.fulignoli@ericsson.com Wed Jan 13 09:16:42 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1843A69A3; Wed, 13 Jan 2010 09:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOuDVClNhJIj; Wed, 13 Jan 2010 09:16:41 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 94BEF3A67CC; Wed, 13 Jan 2010 09:16:40 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-0d-4b4dfff4283f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id F9.53.04178.4FFFD4B4; Wed, 13 Jan 2010 18:16:36 +0100 (CET) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jan 2010 18:16:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jan 2010 18:16:35 +0100 Message-ID: <93DFCD4B101EB440B5B72997456C5F9404C4AE14@esealmw118.eemea.ericsson.se> In-Reply-To: <4B4DFC51.8050301@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document Thread-Index: AcqUcgV9NOe7mrLYRCa1NLGN+7sF9wAAgUUg References: <4B4DFC51.8050301@pi.nu> From: "Annamaria Fulignoli" To: "Loa Andersson" , , , , X-OriginalArrivalTime: 13 Jan 2010 17:16:36.0241 (UTC) FILETIME=[293C3810:01CA9474] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 13 Jan 2010 10:00:09 -0800 Subject: Re: [CCAMP] [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 17:16:42 -0000 Yes/support BR Annamaria -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Loa Andersson Sent: mercoled=EC 13 gennaio 2010 18.01 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls-tp] poll on making = draft-weingarten-mpls-tp-linear-protection an mpls wg document All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 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. Please note that it is a conscious decision by the wg chair to poll the = linear-protection document prior to the ring-protection document, since = we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa -- _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From jordan.britnell@bell.ca Wed Jan 13 09:18:55 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326023A687F; Wed, 13 Jan 2010 09:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITKlHYkX0zZ3; Wed, 13 Jan 2010 09:18:54 -0800 (PST) Received: from mail134.messagelabs.com (mail134.messagelabs.com [85.158.137.35]) by core3.amsl.com (Postfix) with ESMTP id 8AAD33A67E9; Wed, 13 Jan 2010 09:18:53 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jordan.britnell@bell.ca X-Msg-Ref: server-13.tower-134.messagelabs.com!1263403118!57917574!15 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [206.47.0.177] Received: (qmail 11315 invoked from network); 13 Jan 2010 17:18:47 -0000 Received: from dm1c8e.bell.ca (HELO TLS.Exchange.Bell.ca) (206.47.0.177) by server-13.tower-134.messagelabs.com with RC4-SHA encrypted SMTP; 13 Jan 2010 17:18:47 -0000 Received: from hub01-wyn.bell.corp.bce.ca (142.182.199.48) by dm1c8e.exchange3.bell.ca (198.235.102.108) with Microsoft SMTP Server id 8.1.358.0; Wed, 13 Jan 2010 12:18:46 -0500 Received: from MBX01.bell.corp.bce.ca ([142.182.199.57]) by hub01-wyn.bell.corp.bce.ca ([142.182.199.48]) with mapi; Wed, 13 Jan 2010 12:18:39 -0500 From: To: , , , , , Date: Wed, 13 Jan 2010 12:18:37 -0500 Thread-Topic: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document Thread-Index: AcqUcgT/CqHWXbshQuCgRQHJYMzFdAAACAGgAACSWrA= Message-ID: References: <4B4DFC51.8050301@pi.nu> <077E41CFFD002C4CAB7DFA4386A5326401B968CB@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326401B968CB@DEMUEXC014.nsn-intra.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-Mailman-Approved-At: Wed, 13 Jan 2010 10:00:09 -0800 Subject: Re: [CCAMP] [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 17:18:55 -0000 Support.=20 ________________________________________ Jordan Britnell IP Technology Research BCE/Bell Canada (416) 215-3729 jordan.britnell@bell.ca -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Spr= echer, Nurit (NSN - IL/Hod HaSharon) Sent: January 13, 2010 12:03 PM To: ext Loa Andersson; mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe= 3@ietf.org Subject: Re: [mpls] [mpls-tp] poll on making draft-weingarten-mpls-tp-linea= r-protection an mpls wg document Yes/Support. -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Loa Andersson Sent: Wednesday, January 13, 2010 7:01 PM To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 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. Please note that it is a conscious decision by the wg chair to poll the linear-protection document prior to the ring-protection document, since we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa --=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From wwwrun@core3.amsl.com Wed Jan 13 15:15:35 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 064433A67E1; Wed, 13 Jan 2010 15:15:35 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100113231535.064433A67E1@core3.amsl.com> Date: Wed, 13 Jan 2010 15:15:35 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] Last Call: draft-ietf-ccamp-pc-spc-rsvpte-ext (RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network.) to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 23:15:35 -0000 The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network. ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-01-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-spc-rsvpte-ext-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17164&rfc_flag=0 From wwwrun@core3.amsl.com Wed Jan 13 15:17:35 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 16FF628C0E7; Wed, 13 Jan 2010 15:17:35 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100113231735.16FF628C0E7@core3.amsl.com> Date: Wed, 13 Jan 2010 15:17:35 -0800 (PST) Cc: ccamp mailing list , Internet Architecture Board , ccamp chair , RFC Editor Subject: [CCAMP] Protocol Action: 'Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks' to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 23:17:35 -0000 The IESG has approved the following document: - 'Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks ' as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-11.txt Technical Summary 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 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 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. This document received thorough review in the IPPM and BM working groups. Personnel Lou Berger (lberger@labn.net) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD From wwwrun@core3.amsl.com Wed Jan 13 15:19:28 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 666F13A688B; Wed, 13 Jan 2010 15:19:28 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100113231928.666F13A688B@core3.amsl.com> Date: Wed, 13 Jan 2010 15:19:28 -0800 (PST) Cc: ccamp mailing list , Internet Architecture Board , ccamp chair , RFC Editor Subject: [CCAMP] Protocol Action: 'Data Channel Status Confirmation Extensions for the Link Management Protocol' to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2010 23:19:28 -0000 The IESG has approved the following document: - 'Data Channel Status Confirmation Extensions for the Link Management Protocol ' as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-confirm-data-channel-status-09.txt Technical Summary This document defines an extention to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent LSRs to confirm data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found. Working Group Summary This document received adequate attention and discussion in the working group in its early revisions. The document has been laregly stable for quite some time, mainly needing revisions as part of the publication process. Document Quality 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. Private comment to the AD reveal the existence of two implementations. Personnel Lou Berger (lberger@labn.net) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. RFC Editor Note Section 4.1.3 ADD to the end of the section The ERROR_CODE object in this message has a new Class Type (see Section 7.3), but is formed as the ERROR_CODE object defined in [RFC4204]. The following Error Codes are defined: 0x01 = Channel Status Confirmation Procedure not supported 0x02 = Unwilling to Confirm END --- Section 4.4 OLD Some nodes running in the network may only support the LMP Message Types, which are already defined in [RFC4204]. The three new types of LMP message defined in this document can not be recognized by these nodes. The unknown message behavior is not being specified in [RFC4204], it's suggested to discard the unknown message silently. The mechanism defined in this document presumes a certain non- standard behavior of existing/non-document supporting nodes. To use this mechanism all nodes MUST have the extensions described in this document for compatibility. NEW Some nodes running in the network might only support the LMP Message Types which are already defined in [RFC4204]. The three new types of LMP message defined in this document can not be recognized by these nodes. The behavior of an LMP node that receives an unknown message is not specified in [RFC4204] and will be clarified in a separate document. Since the behavior of legacy nodes must be assumed to be unknown, this document assumes that a deployment intended to support the function described in this document will consist completely of nodes that support the protocol extensions described in this document. In future, it may be the case that LMP will be extended to allow function-support to be detected. In that case, it may become possible to deploy this function in a mixed environment. END --- Section 5 s/local police/local policy/ --- Section 5 OLD ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable transmission mechanisms. If after the retry limit is reached, a ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack message is not received by the SENDER, the SENDER SHOULD terminate the data channel confirmation procedure. NEW ConfirmDataChannelStatus SHOULD be sent using LMP [RFC4204] reliable transmission mechanisms. If after the retry limit is reached, a ConfirmDataChannelStatusAck message or a ConfirmDataChannelStatusNack message is not received by the SENDER, the SENDER SHOULD terminate the data channel confirmation procedure and SHOULD raise an alert to the management plane. END --- Section 6 OLD The operation of the procedures described in this document does not of themselves constitute a security risk since they do not cause any change in network state. It would be possible, if the messages were intercepted or spoofed to cause bogus alerts in the management plane and so the use of the LMP security measures are RECOMMENDED. NEW The operation of the procedures described in this document does not of themselves constitute a security risk since they do not cause any change in network state. It would be possible, if the messages were intercepted or spoofed to cause bogus alerts in the management plane and so the use of the LMP security measures described in [RFC4204] are RECOMMENDED. END --- NEW 7.3. NEW LMP Error_Code Class Type IANA maintains the "Link Management Protocol (LMP)" registry which has a subregistry called "LMP Object Class name space and Class type (C-Type)". This subregistry has an entry for the ERROR_CODE object. IANA is requested to allocate a new value for an ERROR_CODE class type as follows. C-Type Description Reference ------ ------------------------ --------- 4 ConfirmDataChannelStatusNack [This-ID] END From diego.caviglia@ericsson.com Wed Jan 13 23:53:29 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502D43A6948; Wed, 13 Jan 2010 23:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ze-WO9dq1hSE; Wed, 13 Jan 2010 23:53:28 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 63D423A6942; Wed, 13 Jan 2010 23:53:27 -0800 (PST) X-AuditID: c1b4fb24-b7bb6ae000001052-61-4b4ecd71e5fb Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id CE.CE.04178.17DCE4B4; Thu, 14 Jan 2010 08:53:21 +0100 (CET) Received: from esealmw110.eemea.ericsson.se ([153.88.200.78]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Jan 2010 08:52:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jan 2010 08:52:11 +0100 Message-ID: In-Reply-To: <4B4DFC51.8050301@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document Thread-Index: AcqUcgUBglFKQurGTViBMde2E6EnFAAfHB6g References: <4B4DFC51.8050301@pi.nu> From: "Diego Caviglia" To: "Loa Andersson" , , , , X-OriginalArrivalTime: 14 Jan 2010 07:52:33.0225 (UTC) FILETIME=[87A38B90:01CA94EE] X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 07:53:29 -0000 Yes support Ciao D line DIEGO CAVIGLIA=20 Strategic Product Manager=20 Ericsson Italy Product Line PAIB Via A. Negrone 1/A Genoa, Italy Phone +390106003736 Mobile +393357181762 diego.caviglia@ericsson.com www.ericsson.com=20 Ericsson This Communication is Confidential. We only send and receive email on = the basis of the term set out at www.ericsson.com/email_disclaimer=20 -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On = Behalf Of Loa Andersson Sent: mercoled=EC 13 gennaio 2010 18.01 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls-tp] poll on making = draft-weingarten-mpls-tp-linear-protection an mpls wg document All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 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. Please note that it is a conscious decision by the wg chair to poll the linear-protection document prior to the ring-protection document, since we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa --=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From eric.gray@ericsson.com Thu Jan 14 06:42:37 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27F23A67DB; Thu, 14 Jan 2010 06:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQx6yOA23CcO; Thu, 14 Jan 2010 06:42:37 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 0D54B3A67D9; Thu, 14 Jan 2010 06:42:36 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o0EEgmr2007381; Thu, 14 Jan 2010 08:42:49 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.164]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 14 Jan 2010 09:42:32 -0500 From: Eric Gray To: Loa Andersson , "mpls-tp@ietf.org" , "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" Date: Thu, 14 Jan 2010 09:42:31 -0500 Thread-Topic: [mpls] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document Thread-Index: AcqUchvOyu3COQvzSu2oIn5kgTUmpwAtaJVQ Message-ID: References: <4B4DFC51.8050301@pi.nu> In-Reply-To: <4B4DFC51.8050301@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 Subject: Re: [CCAMP] [mpls] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2010 14:42:38 -0000 Yes.=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Wednesday, January 13, 2010 12:01 PM To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls] poll on making draft-weingarten-mpls-tp-linear-protection a= n mpls wg document All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 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. Please note that it is a conscious decision by the wg chair to poll the linear-protection document prior to the ring-protection document, since we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa --=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From bao.yuanlin@zte.com.cn Thu Jan 14 16:47:22 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5B423A6A0C; Thu, 14 Jan 2010 16:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 suGSl6UoMF43; Thu, 14 Jan 2010 16:47:21 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id C18C73A6878; Thu, 14 Jan 2010 16:47:11 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111644429685300; Fri, 15 Jan 2010 08:13:30 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 75400.4803937422; Fri, 15 Jan 2010 08:47:05 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id o0F0l1a1018238; Fri, 15 Jan 2010 08:47:01 +0800 (CST) (envelope-from Bao.Yuanlin@zte.com.cn) In-Reply-To: <4B4DFC51.8050301@pi.nu> To: Loa Andersson MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: Bao.Yuanlin@zte.com.cn Date: Fri, 15 Jan 2010 08:48:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-01-15 08:47:00, Serialize complete at 2010-01-15 08:47:00 Content-Type: multipart/alternative; boundary="=_alternative 00044C4B482576AC_=" X-MAIL: mse1.zte.com.cn o0F0l1a1018238 Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, ccamp-bounces@ietf.org, mpls-tp@ietf.org Subject: [CCAMP] =?gb2312?b?tPC4tDogIHBvbGwgb24gbWFraW5nIGRyYWZ0LXdlaW5n?= =?gb2312?b?YXJ0ZW4tbXBscy10cC1saW5lYXItcHJvdGVjdGlvbiBhbiBtcGxzIHdnIGRv?= =?gb2312?b?Y3VtZW50?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 00:47:22 -0000 This is a multipart message in MIME format. --=_alternative 00044C4B482576AC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 WWVzIHN1cHBvcnQNCg0KDQoNCg0KWXVhbmxpbiBCYW8NClpURSBDb3Jwb3JhdGlvbg0KDQoNCg0K DQoNCkxvYSBBbmRlcnNzb24gPGxvYUBwaS5udT4gDQq3orz+yMs6ICBjY2FtcC1ib3VuY2VzQGll dGYub3JnDQoyMDEwLTAxLTE0IDAxOjAxDQoNCsrVvP7Iyw0KbXBscy10cEBpZXRmLm9yZywgbXBs c0BpZXRmLm9yZywgY2NhbXBAaWV0Zi5vcmcsIHB3ZTNAaWV0Zi5vcmcNCrOty80NCg0K1vfM4g0K W0NDQU1QXSBwb2xsIG9uIG1ha2luZyBkcmFmdC13ZWluZ2FydGVuLW1wbHMtdHAtbGluZWFyLXBy b3RlY3Rpb24gYW4gbXBscyANCndnIGRvY3VtZW50DQoNCg0KDQoNCg0KDQpBbGwsDQoNCnRoaXMg aXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIG9uIG1ha2luZw0KDQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC13ZWluZ2FydGVuLW1wbHMtdHAtbGluZWFyLXByb3RlY3Rpb24tMDUN Cg0KYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KDQpTZW5kIGEgbWFpbCB0byB0aGUg bXBscy10cEBpZXRmLm9yZyBtYWlsaW5nIGxpc3QsDQppbmRpY2F0aW5nICJ5ZXMvc3VwcG9ydCIg b3IgIm5vL2RvIG5vdCBzdXBwb3J0Ii4NCg0KQ29tbWVudHMgb24gdGhlIGNvbnRlbnQgb2YgdGhl IGRyYWZ0IHNob3VsZCBiZSBzZW50IHRvIHRoZSBzYW1lDQptYWlsaW5nIGxpc3Qgd2l0aCBhIGRp ZmZlcmVudCBzdWJqZWN0IGxpbmUuDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgaXMgYSBjb25zY2lv dXMgZGVjaXNpb24gYnkgdGhlIHdnIGNoYWlyIHRvIHBvbGwNCnRoZSBsaW5lYXItcHJvdGVjdGlv biBkb2N1bWVudCBwcmlvciB0byB0aGUgcmluZy1wcm90ZWN0aW9uDQpkb2N1bWVudCwgc2luY2Ug d2Ugd2FudCB0byBtYWtlIHJvb20gZm9yIHNlcGFyYXRlZCBkaXNjdXNzaW9ucyBvbg0KdGhlIHR3 byBkb2N1bWVudHMuDQoNClRoZSBwb2xsIGVuZHMgRnJpZGF5IGp1YW51YXJ5IDI5LCAyMDEwLg0K DQovTG9hDQotLSANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoNCg0KDQo= --=_alternative 00044C4B482576AC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllcyBzdXBwb3J0PC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5ZdWFubGluIEJhbzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ WlRFIENvcnBvcmF0aW9uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+PGI+TG9hIEFuZGVyc3NvbiAmbHQ7bG9hQHBpLm51Jmd0OzwvYj4NCjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtjY2FtcC1ib3VuY2Vz QGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAt MDEtMTQgMDE6MDE8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+bXBscy10cEBpZXRmLm9yZywgbXBsc0BpZXRmLm9yZywgY2NhbXBAaWV0Zi5v cmcsDQpwd2UzQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2 Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5bQ0NBTVBdIHBvbGwgb24gbWFraW5nIGRyYWZ0LXdlaW5nYXJ0 ZW4tbXBscy10cC1saW5lYXItcHJvdGVjdGlvbg0KYW4gbXBscyB3ZyBkb2N1bWVudDwvZm9udD48 L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJs ZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QWxsLDxi cj4NCjxicj4NCnRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIG9uIG1ha2luZzxicj4N Cjxicj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdlaW5nYXJ0ZW4tbXBscy10 cC1saW5lYXItcHJvdGVjdGlvbi0wNTxicj4NCjxicj4NCmFuIE1QTFMgd29ya2luZyBncm91cCBk b2N1bWVudC48YnI+DQo8YnI+DQpTZW5kIGEgbWFpbCB0byB0aGUgbXBscy10cEBpZXRmLm9yZyBt YWlsaW5nIGxpc3QsPGJyPg0KaW5kaWNhdGluZyAmcXVvdDt5ZXMvc3VwcG9ydCZxdW90OyBvciAm cXVvdDtuby9kbyBub3Qgc3VwcG9ydCZxdW90Oy48YnI+DQo8YnI+DQpDb21tZW50cyBvbiB0aGUg Y29udGVudCBvZiB0aGUgZHJhZnQgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIHNhbWU8YnI+DQptYWls aW5nIGxpc3Qgd2l0aCBhIGRpZmZlcmVudCBzdWJqZWN0IGxpbmUuPGJyPg0KPGJyPg0KUGxlYXNl IG5vdGUgdGhhdCBpdCBpcyBhIGNvbnNjaW91cyBkZWNpc2lvbiBieSB0aGUgd2cgY2hhaXIgdG8g cG9sbDxicj4NCnRoZSBsaW5lYXItcHJvdGVjdGlvbiBkb2N1bWVudCBwcmlvciB0byB0aGUgcmlu Zy1wcm90ZWN0aW9uPGJyPg0KZG9jdW1lbnQsIHNpbmNlIHdlIHdhbnQgdG8gbWFrZSByb29tIGZv ciBzZXBhcmF0ZWQgZGlzY3Vzc2lvbnMgb248YnI+DQp0aGUgdHdvIGRvY3VtZW50cy48YnI+DQo8 YnI+DQpUaGUgcG9sbCBlbmRzIEZyaWRheSBqdWFudWFyeSAyOSwgMjAxMC48YnI+DQo8YnI+DQov TG9hPGJyPg0KLS0gPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+DQpDQ0FNUEBpZXRmLm9yZzxicj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8YnI+DQo8YnI+DQo8 L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 00044C4B482576AC_=-- From root@core3.amsl.com Fri Jan 15 13:15:01 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A44693A6976; Fri, 15 Jan 2010 13:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100115211501.A44693A6976@core3.amsl.com> Date: Fri, 15 Jan 2010 13:15:01 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 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 Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework Author(s) : D. Fedyk, et al. Filename : draft-ietf-ccamp-gmpls-ethernet-arch-09.txt Pages : 21 Date : 2010-01-15 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 MPLS 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-09.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-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-15130226.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Fri Jan 15 13:45:26 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9E6423A695F; Fri, 15 Jan 2010 13:45:26 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100115214526.9E6423A695F@core3.amsl.com> Date: Fri, 15 Jan 2010 13:45:26 -0800 (PST) Cc: ccamp mailing list , Internet Architecture Board , ccamp chair , RFC Editor Subject: [CCAMP] Document Action: 'Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework' to Informational RFC X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2010 21:45:26 -0000 The IESG has approved the following document: - 'Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework ' as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-09.txt Technical Summary 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 MPLS 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. Working Group Summary Nothing of note. Document Quality This is an Informational I-D. The I-D has had a good level of discussion and review. Several liaisons were exchanged with IEEE and MEF during CCAMP's Ethernet work to ensure compatibility and cooperation between the SDOs, e.g.: https://datatracker.ietf.org/documents/LIAISON/file396.txt http://ccamp.labn.net/old_ccamp/IEEE_240707.txt Personnel Deborah Brungard (db3546@att.com) is the document shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the responsible AD. From db3546@att.com Mon Jan 18 14:07:35 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944D73A67D1 for ; Mon, 18 Jan 2010 14:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 YcbO+kFHqv7H for ; Mon, 18 Jan 2010 14:07:34 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 9EB7F3A67B7 for ; Mon, 18 Jan 2010 14:07:34 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1263852449!43101416!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 32040 invoked from network); 18 Jan 2010 22:07:30 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Jan 2010 22:07:30 -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 o0IM7OMQ012917 for ; Mon, 18 Jan 2010 17:07:24 -0500 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 o0IM7IJN012844 for ; Mon, 18 Jan 2010 17:07:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jan 2010 17:07:22 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 77 - Important Dates Thread-Index: AcqYipwDioG5bde1RO6UDUvDRQLdSg== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" Subject: [CCAMP] IETF 77 - Important Dates X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2010 22:07:35 -0000 * 2010-02-26 (Friday): Final agenda to be published. * 2010-03-01 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PST (01:00 Tuesday, March 2 UTC), upload using IETF ID Submission Tool . * 2010-03-08 (Monday): Internet Draft final submission cut-off by 17:00 PST (01:00 Tuesday, March 9 UTC), upload using IETF ID Submission Tool . * 2010-03-10 (Wednesday): Draft Working Group agendas due by 17:00 PST (01:00 Thursday, March 11 UTC), upload using IETF Meeting Materials Management Tool . * 2010-03-12 (Friday): Early Bird registration and payment cut-off at 17:00 PST (01:00 Saturday, March 13 UTC). * 2010-03-15 (Monday): Revised Working Group agendas due by 17:00 PDT (24:00 UTC), upload using IETF Meeting Materials Management Tool . * 2010-03-15 (Monday): Registration cancellation cut-off at 17:00 PDT (24:00 UTC). * 2010-03-19 (Friday): Final Pre-Registration and Pre-Payment cut-off at 17:00 PDT (24:00 UTC). * 2010-03-21 - 2010-03-26: 77th IETF Meeting in Anaheim, California, USA From Senoo.Shoichiro@dc.MitsubishiElectric.co.jp Mon Jan 18 19:16:30 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07CBE3A6A1D for ; Mon, 18 Jan 2010 19:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.71 X-Spam-Level: *** X-Spam-Status: No, score=3.71 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=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 RSCADlNOqbK0 for ; Mon, 18 Jan 2010 19:16:29 -0800 (PST) Received: from mx05.melco.co.jp (mx05.melco.co.jp [192.218.140.145]) by core3.amsl.com (Postfix) with ESMTP id B32A03A6969 for ; Mon, 18 Jan 2010 19:16:29 -0800 (PST) Received: from mr05.melco.co.jp (mr05 [133.141.98.165]) by mx05.melco.co.jp (Postfix) with ESMTP id 2066A5CD8A for ; Tue, 19 Jan 2010 12:16:26 +0900 (JST) Received: from mr05.melco.co.jp (localhost [127.0.0.1]) by mr05.imss (Postfix) with ESMTP id F270EA8F4 for ; Tue, 19 Jan 2010 12:16:25 +0900 (JST) Received: from elgw.isl.melco.co.jp (unknown [133.141.13.130]) by mr05.melco.co.jp (Postfix) with ESMTP id C30B4A8EC for ; Tue, 19 Jan 2010 12:16:25 +0900 (JST) Received: from iswall2a.isl.melco.co.jp (iswall2a.isl.melco.co.jp [10.74.245.24]) by elgw.isl.melco.co.jp (Postfix) with ESMTP id 948DE31F3CD for ; Tue, 19 Jan 2010 12:16:25 +0900 (JST) Received: from iswall2a.isl.melco.co.jp (localhost.localdomain [127.0.0.1]) by localhost.isl.melco.co.jp (Postfix) with ESMTP id 3327D22CBCB for ; Tue, 19 Jan 2010 12:16:25 +0900 (JST) Received: from LeakStopper186 (stopper.isl.melco.co.jp [10.74.245.35]) by iswall2a.isl.melco.co.jp (Postfix) with SMTP id 1CBAB22CBB5 for ; Tue, 19 Jan 2010 12:16:25 +0900 (JST) Received: (qmail 12113 invoked by uid 507); 19 Jan 2010 12:16:25 +0900 Received: from unknown (HELO ELSTEFANY) (10.74.8.38) by 0 with SMTP; 19 Jan 2010 12:15:52 +0900 From: "Shoichiro Seno" To: , Date: Tue, 19 Jan 2010 12:15:52 +0900 Message-ID: <9DF91B3ECD8E4551B29D2966672C4C61@ad.melco.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-index: AcqYtTHqIuCpJnDtRyCuJ37u9PFqhwAAE5Qw Subject: [CCAMP] iPOP 2010 Call for Presentation X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 03:16:30 -0000 Dear CAMP, PCE, MPLS and MPLS-TP subscribers, (Apologies for multiple copies, appreciated if you can forward to potentially interested people.) ----------------------------------------------------------------------- Call for Presentation 6th International Conference on IP + Optical Network (iPOP 2010) June 10-11, 2010 NTT Musashino R&D Center, Tokyo, Japan http://www.pilab.jp/ipop2010/ The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. Important Dates: Submission deadline of one-page abstract: February 19, 2010 Notification of acceptance: April 2, 2010 Submission deadline of final presentation slides: April 23, 2010 The Technical Program Committee for iPOP 2010 is soliciting presentation proposals for this conference. Protocol design, experiment, theory, implementation, and operational experiences are solicited. The topics of the conference will include but not limited to the following: * GMPLS/ASON technologies * GMPLS Network management, OA&M * Multi-layer network (MLN) / Multi-region network (MRN) * Path Computation Element (PCE), Traffic engineering * Inter-area/Inter-AS network * L1VPN, Bandwidth on Demand, and Photonic Grid * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, Impairment management * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet transport technologies * Carrier Ethernet and MPLS-TP * Photonic Network for NxGN and NwGN * Application with high-bandwidth demand * Testbed, field trial If you wish to submit a topic for consideration, please send an Extended Abstracts of a 400 words and a maximum of 1 page, including figures and diagrams, speaker's name, affiliation, and contact information to the Technical Program Committee at ipop2010-CFP@pilab.jp. Please see http://www.pilab.jp/ipop2010/ for more details. General Chairs: Tomonori Aoyama, Keio University, Japan Bijan Jabbari, ISOCORE, USA Hisashi Koumura, NTT, Japan Organization Committee Co-Chairs: Naoaki Yamanaka, Keio University, Japan Atsushi Hiramatsu, NTT, Japan Soichiro Araki, NEC, Japan Exhibition Committee Co-Chairs: Kohei Shiomoto, NTT, Japan Munefumi Tsurusawa, KDDI R&D, Japan Technical Program Committee Co-Chairs: Eiji Oki, University of Electro-Communications, Japan Monique Morrow, Cisco Systems, USA -------------------------------------------------------------------------------- - Kind regards, Sho Seno Publication Chair, iPOP 2010 -- Shoichiro Seno (E-mail) Senoo.Shoichiro@dc.MitsubishiElectric.co.jp Information Technology R&D Center, Mitsubishi Electric Corporation From lufang@cisco.com Mon Jan 18 21:13:05 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87BA3A6905; Mon, 18 Jan 2010 21:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sl4UrnAVLEJY; Mon, 18 Jan 2010 21:13:05 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 91DB03A6861; Mon, 18 Jan 2010 21:13:04 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACvOVEtAZnwM/2dsb2JhbADAJ5UChDME X-IronPort-AV: E=Sophos;i="4.49,301,1262563200"; d="scan'208";a="80771531" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 19 Jan 2010 05:13:00 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.170]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o0J5D05u010654; Tue, 19 Jan 2010 05:13:00 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jan 2010 23:13:00 -0600 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, 18 Jan 2010 23:12:58 -0600 Message-ID: <238542D917511A45B6B8AA806E875E25511A96@XMB-RCD-201.cisco.com> In-Reply-To: <4B4DFC51.8050301@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document thread-index: AcqUcgRvkHymg0r/THuxP9uDW+uErwEU6vsA References: <4B4DFC51.8050301@pi.nu> From: "Luyuan Fang (lufang)" To: "Loa Andersson" , , , , X-OriginalArrivalTime: 19 Jan 2010 05:13:00.0222 (UTC) FILETIME=[11BFF5E0:01CA98C6] Subject: Re: [CCAMP] [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 05:13:06 -0000 yes/support. Luyuan -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: 13 January 2010 12:01 To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [mpls-tp] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 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. Please note that it is a conscious decision by the wg chair to poll the linear-protection document prior to the ring-protection document, since we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa -- _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From Alan.Elder@metaswitch.com Tue Jan 19 04:32:24 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E183A68D9 for ; Tue, 19 Jan 2010 04:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T3qSE3ID5XZ for ; Tue, 19 Jan 2010 04:32:16 -0800 (PST) Received: from enfiets2.dataconnection.com (enfiets2.dataconnection.com [192.91.191.39]) by core3.amsl.com (Postfix) with ESMTP id 2CB263A6A7F for ; Tue, 19 Jan 2010 04:32:16 -0800 (PST) Received: from ENFIMBOX1.ad.datcon.co.uk (172.18.10.27) by enfiets2.dataconnection.com (172.18.4.22) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 19 Jan 2010 12:33:46 +0000 Received: from ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) by ENFIMBOX1.ad.datcon.co.uk ([172.18.10.27]) with mapi; Tue, 19 Jan 2010 12:32:11 +0000 From: Alan Elder To: "ccamp@ietf.org" Date: Tue, 19 Jan 2010 12:32:10 +0000 Thread-Topic: Comments on draft draft-ietf-ccamp-pc-spc-rsvpte-ext-06 Thread-Index: AcqZA2vCyTtNSlvFTzWPr3zR3WKwzQ== Message-ID: <11DE3EEC54A8A44EAD99D8C0D3FD7207951D944BDA@ENFIMBOX1.ad.datcon.co.uk> 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_11DE3EEC54A8A44EAD99D8C0D3FD7207951D944BDAENFIMBOX1adda_" MIME-Version: 1.0 Subject: [CCAMP] Comments on draft draft-ietf-ccamp-pc-spc-rsvpte-ext-06 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2010 12:34:10 -0000 --_000_11DE3EEC54A8A44EAD99D8C0D3FD7207951D944BDAENFIMBOX1adda_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ccamp, The main MP to CP procedure looks good. It's not clear whether the seconda= ry MP to CP procedure is a core requirement or an optional extra. I think CP to MP handover has some bugs, relating to when PathTears are sen= t. Detailed comments and suggestions below. Cheers, Alan. 1) Is the alternative MP to CP procedure MUST or MAY? I suggest "MAY" Section 4 describes "primary" and "alternative" MP to CP procedures. I sug= gest we should mark these respectively as MUST and MAY, as indicated in Sec= tion 3. It's good to have a minimal subset of procedures marked as MUST. A note in section 5 gives both alternatives equal weight. This doesn't see= m right - we don't want some implementations doing one and some doing the o= ther. I suggest we remove this: "The full ERO method and the partial/no ERO one do not exclude each other; = both methods are required." If the alternative method MAY be implemented, we need to clarify the error = reported by a transit node that does not support the alternative mechanism.= I suggest using a PathErr with the Handover Failed error code, this could= be added to Section 4.1. 2) Where can PathTear flow during CP to MP handover? I suggest "nowhere" Section 4.4 states: "...the ingress node MUST NOT send a PathTear message b= efore a Resv message containing the H bit is received." This is right - a PathTear would transfer resources to the management plane= prematurely. But why does this apply specially to ingress? A PathTear or= iginated from a transit node would also cause premature transfer of LSP own= ership. I suggest PathTear should not be sent by any node during handover = (see text below). 3) CP to MP handover procedures do not maintain the LSP on failure The procedure in section 7.2 is good for MP to CP handover. But for CP to = MP handover, sending a PathTear will not achieve the stated objective of ke= eping the LSP in place and CP owned. In order to do that, the PathErr/Path= Tear procedures need to be modified so that the ingress node receives PathE= rr and resignals the Path with H clear. I suggest the following as the definition for PathErr/PathTear procedures, = covering points (2) and (3). "While the H bit is set in Path state, a node MUST NOT send a PathTear when= a failure is detected. Instead, the failure is reported upstream using a = PathErr. The only node that can send a PathTear is the ingress node, and i= t can only do this as a step in the procedures specified in this document. = This applies to both MP to CP and CP to MP handover." 4) Bug in CP to MP procedures, introduced in -05 This was added to Section 4.1 as part of revision -05 " Each LSR that receives a Path message with the H bit set checks to see wh= ether there is any matching Path state. - If matching Path state is found with the H bit set, this is a Path refres= h and should be treated accordingly [RFC3473]. - If matching Path state is found with the H bit clear, this is an error an= d MUST be treated according to the error case description in Section 4.2.1.= 1" This is fine for MP to CP handover. But CP to MP procedures expect to find= matching Path state with the H bit clear. How can the second bullet be su= pported without disabling CP to MP procedures? I suggest this second bullet is updated to indicate that this case is treat= ed according to CP to MP procedures. If CP to MP handover is not supported= on the node then it is treated with PathErr(Handover Failed). 5) "All nodes along the path MUST support"? This seems unusual. Section 8 states that "all nodes along the path MUST support the extension = defined in this draft". Otherwise "This may result in an impact on data tr= affic during the handover procedure." This is unusual behaviour for a new signaling procedure. Usually, lack of = support for a signaling feature on some LSRs results in a graceful (signale= d) failure when the feature is used. In this case, it results in undetecte= d loss of an LSP. It is worth clarifying that not all parts of this draft MUST be supported b= y all nodes - rather just the mandatory parts must be supported. For examp= le, if some nodes support the optional CP to MP handover and some do not, t= hen CP to MP failure is signalled gracefully using PathErr signalling (see = point 4 above). Also if some nodes support the alternative MP to CP method= , and some do not, then MP to CP failure is signalled gracefully (see point= 1 above). --_000_11DE3EEC54A8A44EAD99D8C0D3FD7207951D944BDAENFIMBOX1adda_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ccamp,

 

The main MP to=20 CP procedure looks good.  It's not clear whether the=20 secondary MP to CP procedure is a core requirement or an optional=20 extra.

 

I think CP to MP handover&nbs= p;has=20 some bugs, relating to when PathTears are sent.  Detailed comments and= =20 suggestions below.

 

Cheers,

Alan.   =20

 

1)  Is the alternative M= P to CP=20 procedure MUST or MAY?  I suggest "MAY"

Section 4 describes "primary"= and=20 "alternative" MP to CP procedures.  I suggest we should mark thes= e=20 respectively as MUST and MAY, as indicated in Section 3.  It's good to= =20 have a minimal subset of procedures marked as=20 MUST.

 

A note in section 5 give= s=20 both alternatives equal weight.  This doesn't seem righ= t -=20 we don't want some implementations doing one and some doing the other. = ; I=20 suggest we remove this:

"The full ERO method and the= =20 partial/no ERO one do not exclude each other; both methods are=20 required."

 

If the alternative method MAY= be=20 implemented, we need to clarify the error reported by a tran= sit=20 node that does not support the alternative mechanism.  I suggest using a PathErr=20 with the Handover Failed error code, this could be added=20 to Section 4.1. 

 

 

2)  Where can PathTear=20 flow during CP to MP handover?  I suggest=20 "nowhere"

Section 4.4 states: "...the i= ngress=20 node MUST NOT send a PathTear message before a Resv message containing the = H bit=20 is received."

This is right – a PathT= ear would=20 transfer resources to the management plane prematurely.  But why does this apply specially= to=20 ingress?  A PathTear originated from a transit node would also cause=20 premature transfer of LSP ownership. = ;=20 I suggest PathTear should not be sent by any node during handov= er=20 (see=20 text below).

 

 

3)  CP to MP handover=20 procedures do not maintain the LSP on failure

The procedure in section 7.2 = is=20 good for MP to CP handover.  But for CP to MP handover, sending a= =20 PathTear will not achieve the stated objective of keeping the LSP in place<= SPAN=20 class=3D512092112-19012010> and CP owned.  In order to do that,= the=20 PathErr/PathTear procedures need to be modified so that the ingress node=20 receives PathErr and resignals the Path with H clear.

 

I suggest the following=20 as the definition for=20 PathErr/PathTear procedures, covering points (2) and=20 (3).

 

"While the H bit is set in Pa= th=20 state, a node MUST NOT send a PathTear when a failure is detected. =20 Instead, the failure is reported upstream using a PathErr.  The only n= ode=20 that can send a PathTear is the ingress node, and it can only do this = as a=20 step in the procedures specified in this document. This applies to both MP = to CP=20 and CP to MP handover." 

 

 

4)  Bug in CP to MP= =20 procedures, introduced in -05

This was added to Section 4.1= as=20 part of revision -05
" Each LSR that receives a Path message with the H = bit=20 set checks to see whether there is any matching Path=20 state.

- If matching Path state is f= ound=20 with the H bit set, this is a Path refresh and should be treated accordingl= y=20 [RFC3473].
- If matching Path state is found with the H bit clear, this = is an=20 error and MUST be treated according to the error case description in Sectio= n=20 4.2.1.1"

 

This is fine for MP to CP=20 handover.  But CP to MP procedures expect to find matching P= ath=20 state with the H bit clear.  How can the second bullet be supported wi= thout=20 disabling CP to MP procedures?

 

I suggest this second bullet = is=20 updated to indicate that this case is treated according to CP to=20 MP procedures.  If CP to= MP=20 handover is not supported on the node then it=20 is treated with PathErr(Handover Failed).

 

 

5)  "All nodes along the= =20 path MUST support"? This seems unusual.

Section 8 states that=20 “all nodes along the path MUST support the extension defined in = this=20 draft”.  Otherwise "This may result in an impact on data traffic= during the=20 handover procedure." 

 

This is unusual behaviour for= a new=20 signaling procedure.  Usually, lack of support for a signaling feature= on=20 some LSRs results in a graceful (signaled) failure when the feature is=20 used.  In this case, it results in undetected loss of an LSP.=20

 

<= SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Tim= es New Roman'; mso-ansi-language: EN-GB; mso-fareast-language: EN-GB; mso-b= idi-language: AR-SA">It=20 is worth clarifying that not all parts of this draft MUST be supported by a= ll=20 nodes – rather just the mandatory parts must be supported.  For example, if some nodes suppor= t the=20 optional CP to MP handover and some do not, then CP to MP failure is signal= led=20 gracefully using PathErr signalling (see point 4 above).  Also if some nodes support the=20 alternative MP to CP method, and some do not, then MP to CP failure is sign= alled=20 gracefully (see point 1 above). 
--_000_11DE3EEC54A8A44EAD99D8C0D3FD7207951D944BDAENFIMBOX1adda_-- From danli@huawei.com Wed Jan 20 01:14:36 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52A913A6804 for ; Wed, 20 Jan 2010 01:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, 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 1NHBLXiVbGuw for ; Wed, 20 Jan 2010 01:14:35 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 6E1AD3A6951 for ; Wed, 20 Jan 2010 01:14:17 -0800 (PST) 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 <0KWJ00CS5GBE8L@szxga03-in.huawei.com> for ccamp@ietf.org; Wed, 20 Jan 2010 17:14:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWJ003FGGBDIK@szxga03-in.huawei.com> for ccamp@ietf.org; Wed, 20 Jan 2010 17:14:01 +0800 (CST) Received: from l37133a ([10.70.77.58]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWJ00A5FGBDF1@szxml06-in.huawei.com> for ccamp@ietf.org; Wed, 20 Jan 2010 17:14:01 +0800 (CST) Date: Wed, 20 Jan 2010 17:14:01 +0800 From: Dan Li To: ccamp@ietf.org Message-id: <00d501ca99b0$e7d043c0$3a4d460a@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_G1ahk/fwxSkqAeKfh5+a1g)" X-Priority: 3 X-MSMail-priority: Normal References: <4AD74572.2070508@labn.net> Subject: [CCAMP] Remain issue with lambda-label 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, 20 Jan 2010 09:14:36 -0000 This is a multi-part message in MIME format. --Boundary_(ID_G1ahk/fwxSkqAeKfh5+a1g) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi all, On behalf of the authors of lambda-label draft, I would like to continue the discussion on this draft. Please provide your proposal on the mailing list. BTW, the latest version of lambda-label draft can be found at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g-694-lambda-labels-05 Thanks, Authors ----- Original Message ----- From: Lou Berger To: draft-ietf-ccamp-gmpls-g-694-lambda-labels@tools.ietf.org ; ccamp@ietf.org Sent: Thursday, October 15, 2009 11:53 PM Subject: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique resource identification 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 --Boundary_(ID_G1ahk/fwxSkqAeKfh5+a1g) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi all,
 
On behalf of the authors of lambda-label draft, I would like to continue the discussion on this draft.
Please provide your proposal on the mailing list.
 
BTW, the latest version of lambda-label draft can be found at:
 
Thanks,
 
Authors
 
 
----- Original Message -----
From: Lou Berger
Sent: Thursday, October 15, 2009 11:53 PM
Subject: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique resource identification

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
--Boundary_(ID_G1ahk/fwxSkqAeKfh5+a1g)-- From root@core3.amsl.com Wed Jan 20 10:00:01 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D2FDC3A6403; Wed, 20 Jan 2010 10:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100120180001.D2FDC3A6403@core3.amsl.com> Date: Wed, 20 Jan 2010 10:00:01 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-mpls-graceful-shutdown-13.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, 20 Jan 2010 18:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Category: Informational Expires: July 19, 2010 January 20, 2010 Author(s) : Z. Ali, et al. Filename : draft-ietf-ccamp-mpls-graceful-shutdown-13.txt Pages : 10 Date : 2010-01-20 MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network. This document provides requirements and protocol mechanisms to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS-TE and its Generalized MPLS (GMPLS) extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-mpls-graceful-shutdown-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-20095757.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Jan 20 10:30:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 016283A6916; Wed, 20 Jan 2010 10:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100120183002.016283A6916@core3.amsl.com> Date: Wed, 20 Jan 2010 10:30:01 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-dcsc-channel-ext-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, 20 Jan 2010 18: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 : 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-03.txt Pages : 11 Date : 2010-01-20 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-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-dcsc-channel-ext-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-20102414.I-D@ietf.org> --NextPart-- From lberger@labn.net Wed Jan 20 10:53:42 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8863A67AF for ; Wed, 20 Jan 2010 10:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=-0.588, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MISSING_HEADERS=1.292] 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 BukxbRXYZCtg for ; Wed, 20 Jan 2010 10:53:41 -0800 (PST) Received: from outbound-mail-01.bluehost.com (outbound-mail-01.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 3B2D43A63EB for ; Wed, 20 Jan 2010 10:53:41 -0800 (PST) Received: (qmail 314 invoked by uid 0); 20 Jan 2010 18:53:37 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy4.bluehost.com with SMTP; 20 Jan 2010 18:53: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:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=RGwjRiDsTZYD+ZnJHppHza1sRqJgAtDZw3vrymVlsL0hLOaWNuw5ZRlggXm8DpHsZVG/lVqnBBYm9Gm9DVmPn09l/T4PFLlG3GBoFNRblUnEIOXs0leuH6/geZ2ivyLV; 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 1NXfgP-00062M-8J for ccamp@ietf.org; Wed, 20 Jan 2010 11:53:37 -0700 Message-ID: <4B575137.3040405@labn.net> Date: Wed, 20 Jan 2010 13:53:43 -0500 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 CC: ccamp@ietf.org References: <20100120183002.016283A6916@core3.amsl.com> In-Reply-To: <20100120183002.016283A6916@core3.amsl.com> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-dcsc-channel-ext-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, 20 Jan 2010 18:53:42 -0000 FYI - this version addresses some minor issues raised by the AD as part of his IESG review. Chnage can be viewed via the usual methods, e.g.: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-ccamp-gmpls-dcsc-channel-ext-03.txt Lou On 1/20/2010 1:30 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > > Title : 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-03.txt > Pages : 11 > Date : 2010-01-20 > > 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-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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From db3546@att.com Wed Jan 20 10:56:26 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F020C3A67AF for ; Wed, 20 Jan 2010 10:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 Ivj51aQ99AOR for ; Wed, 20 Jan 2010 10:56:26 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id DEE6B3A63EB for ; Wed, 20 Jan 2010 10:56:25 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-14.tower-161.messagelabs.com!1264013780!18388235!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 23849 invoked from network); 20 Jan 2010 18:56:21 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Jan 2010 18:56:21 -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 o0KIuEGq027738 for ; Wed, 20 Jan 2010 13:56:15 -0500 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 o0KIu9V4027669 for ; Wed, 20 Jan 2010 13:56:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jan 2010 13:56:14 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed communication to OIF on Routing Thread-Index: AcqaAj05ZOrW23JrTxCHgD+5XYqz/g== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" Subject: [CCAMP] Proposed communication to OIF on Routing 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, 20 Jan 2010 18:56:27 -0000 CCAMP, We need to send a communication to OIF related to their two previous communications to us on routing. Let us know if any comments on this proposal. Deborah and Lou ------------------------ Proposed Communication------------------ Subject: IETF CCAMP Response to OIF on Routing Dear Lyndon, In your October 22nd communication , you requested consideration of two routing related drafts for CCAMP related to OIF testing. On ASON Routing implementation experience "draft-ong-gmpls-ason-routing-exper-00.txt": This document was presented at November's meeting. While it is re-affirming to hear that your development work and interoperability testing confirmed the routing functionality defined in [OSPF-ASON], your use of different sub-TLVs for the testing does not support the transition of [OSPF-ASON] to standards status. Due to the lack of community interest in testing and deploying ASON routing functionality, [OSPF-ASON] was designated as IETF experimental status. If future OIF testing is based on [OSPF-ASON], the discussion on transition of [OSPF-ASON] to standards status could be revisited. On your request for your defined extensions to be given IETF standards status, we remind you of RFC4929: "The definition and publishing of non-standard extensions by other fora, without IETF review, and outside of the IETF publication process, regardless if rationalized as limited to use among fora vendors, or limited to a particular application, or rationalized as allowing timely demos, has the unfortunate potential to hinder interoperability and increase complexity of the protocol, sows confusion in the industry, and circumvents the Internet standards process that exists to ensure protocol implementability. As described in [RFC4775], non-standard extensions, including experimental values, are not to be portrayed as industrial standards whether by an individual vendor, an industry forum, or a standards body." Specifically of concern, we note in your document, the definition of alternative functionality for existing functionality. In section 3.2.1, a new ISCD sub-TLV for advertising "compact" description of connection availability is defined which is non-compatible with standard GMPLS. And, in section 4.4, new sub-TLV is defined as an alternative to [OSPF-Node] which was used in [OSPF-ASON]. You state as justification (section 4.4): "This tested format is functionally equivalent to the format defined in [OSPF-ASON] but is independent of the function of advertising local addresses of a router for MPLS TE LSPs as defined in [OSPF-NODE]." Are you concerned on the use of a common set of procedures by MPLS and GMPLS such that you believe the need to develop alternatives to ensure independence in the advertising? It would be of benefit to the GMPLS community if you would communicate these concerns so they could be addressed properly before developing your own extensions. We recommend that future OIF testing and related drafts be based on [OSPF-ASON]. This would facilitate the alignment of OIF work with CCAMP produced RFCs. On additional functions for ASON routing "draft-theillaud-gmpls-ason-routing-add-fcts-01.txt": The document was introduced at November's meeting and a discussion thread was initiated on CCAMP's exploder on one of the requested functionalities: link associated local connection type. The example provided in Section 3.1 on the need to distinguish high-order and lower-order VC-3s was discussed and it was concluded the functionality is already supported: http://www.ietf.org/mail-archive/web/ccamp/current/msg10716.html You may want to review RFC4202 where this is described: "A way to handle the case where an interface supports multiple branches of the SDH multiplexing hierarchy, multiple Interface Switching Capability Descriptors would be advertised, one per branch. For example, if an interface supports VC-11 and VC-12 (which are not part of same branch of SDH multiplexing tree), then it could advertise two descriptors, one for each one." Section 3 of RFC4202 additionally provides multiple examples which may be helpful. The other proposed functionality, on layer-scoped link attributes, has not been discussed and we welcome the authors of the draft to initiate discussion on the CCAMP list. In your July 23rd communication, you indicated the need to support NSAP format in the advertisement of node local prefixes. We welcome your members to submit a draft detailing the requested functionality. We also direct you to a related discussion that took place in the context of the L1VPN Working Group on November 9, 2005 as reported in http://www.ietf.org/proceedings/64/l1vpn.html. Specifically: Several questions were discussed: - Is there a requirement to support NSAPs? The mechanisms for embedding NSAP in IPv6 (RFC 1888) is now marked as historic. We could bring this back alive simply by republishing, if we need the function. Question is whether we actually need the function. - A poll of room showed slight interest in supporting NSAPs, and no opposition.=20 Since there is very low cost to supporting this it is easy, but we don't usually do things without specific demand. We encourage your members to participate in IETF's CCAMP email exploders and the development of standards to prevent these misunderstandings in the future. Regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs From root@core3.amsl.com Thu Jan 21 09:15:06 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0E5AD3A699A; Thu, 21 Jan 2010 09:15:04 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100121171505.0E5AD3A699A@core3.amsl.com> Date: Thu, 21 Jan 2010 09:15:04 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D ACTION:draft-ietf-ccamp-ethernet-traffic-parameters-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: Thu, 21 Jan 2010 17:15: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 : Ethernet Traffic Parameters Author(s) : D. Papadimitriou Filename : draft-ietf-ccamp-ethernet-traffic-parameters-10.txt Pages : 14 Date : 2010-1-21 This document describes the support of Metro Ethernet Forum (MEF) Ethernet Traffic Parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-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-ethernet-traffic-parameters-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-1-21090606.I-D@ietf.org> --NextPart-- From db3546@att.com Thu Jan 21 13:26:44 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021A83A6765 for ; Thu, 21 Jan 2010 13:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 IOFwWhtlt3Bu for ; Thu, 21 Jan 2010 13:26:43 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id CB6403A67FC for ; Thu, 21 Jan 2010 13:26:42 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-15.tower-146.messagelabs.com!1264109196!12593643!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 4508 invoked from network); 21 Jan 2010 21:26:37 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Jan 2010 21:26:37 -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 o0LLQVNg006750 for ; Thu, 21 Jan 2010 16:26:31 -0500 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 o0LLQPO5006623 for ; Thu, 21 Jan 2010 16:26:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jan 2010 16:26:29 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed communication to OIF on Inverse Multiplexing Thread-Index: AcqauSBfHJGboZNISei5SOFb7drTPwAJVYRw From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" Subject: [CCAMP] Proposed communication to OIF on Inverse Multiplexing X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:26:44 -0000 CCAMP, We need to send a communication to OIF in response to their Oct. 22nd communication. Let us know if any comments on this proposal. Deborah and Lou --------Proposal--------------------- Dear Lyndon, In your October 22nd communication, you requested consideration of a draft on inverse multiplexing "draft-roch-ccamp-gmpls-inv-mux-00.txt". This document was introduced at November's meeting. During CCAMP's Working Group Last Call discussion of "draft-ietf-ccamp-vcat-lcas", the use cases in draft-roch-ccamp-gmpls-inv-mux-00.txt as compared to the scope of draft-ietf-ccamp-vcat-lcas-08.txt were discussed. The use cases and=20 ietms raised in draft-roch-ccamp-gmpls-inv-mux as we understand it are=20 as follows: 1. IMG members are (statically) provisioned. 2. Members might be separately administered and policies may=20 prevent signaling control information related to the IMG to be exchanged in the member signaling. 3. Control plane does not allow piggybacking of IMG information onto=20 its own signaling. The use cases represented in 1. and 2. were considered out-of-scope of=20 the CCAMP document. The scope of the CCAMP document is to support only=20 scenarios where all members are signaled using the defined mechanism. CCAMP support for new functionality must be raised within the Working Group. We suggest that further discussion on these use cases=20 take place based on an updated Internet Draft which is based on existing CCAMP work, i.e., draft-ietf-ccamp-vcat-lcas, which has passed last call. With respect to item 3, in the existing CCAMP work, only the VCAT=20 end-points participate in signaling the IMG information, i.e., the=20 intermediate signaling nodes do not participate in the VCAT call setup.=20 If the end points do not support the CCAMP VCAT signaling mechanism,=20 VCAT isn't provided. Again, the scope of the current work is to support only scenarios where all members are signaled using the defined extension. We welcome future contributions defining your requirements in the form=20 of Internet-drafts. Please note that draft-ietf-ccamp-vcat-lcas is a=20 product of the Working Group. As such, the Working Group will be=20 focused on the reuse of this work in any future related work. As always, we=20 encourage you to follow RFC4929's defined process. Regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs From db3546@att.com Thu Jan 21 13:45:17 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B2A3A67A7 for ; Thu, 21 Jan 2010 13:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 oyxfoEh-Rz4E for ; Thu, 21 Jan 2010 13:45:16 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 12F193A6765 for ; Thu, 21 Jan 2010 13:45:16 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-14.tower-161.messagelabs.com!1264110310!18468181!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 12639 invoked from network); 21 Jan 2010 21:45:11 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Jan 2010 21:45:11 -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 o0LLj4Ql022890 for ; Thu, 21 Jan 2010 16:45:04 -0500 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 o0LLj0Or022830 for ; Thu, 21 Jan 2010 16:45:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jan 2010 16:45:04 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed communication to OIF on Err Messages Thread-Index: Acqa2QCXsQTGNWdSTQ+2MNHsoy+yQQACCaNg From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "CCAMP" Subject: [CCAMP] Proposed communication to OIF on Err Messages X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2010 21:45:17 -0000 CCAMP, We need to send a communication to OIF in response to their July 23rd and Oct. 22nd communications. Let us know if any comments on this proposal. Deborah and Lou ----Proposal---- Dear Lyndon, In your communication of Oct. 22nd, you asked guidance on the following points. > 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. This is incorrect behavior. Per RFC3473: The Notify message does not replace existing error messages. and Notify messages are most commonly generated at nodes that detect an error that will trigger the generation of a PathErr or ResvErr message. The remainder of the procedures discuss the cases where Notify is=20 generated *in addition* to a PathErr or ResvErr. We believe the RFC is sufficiently clear on this point. > 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. Here too implementations must process both Err messages and Notify=20 messages. RFC4872 is an extension to RSVP-TE. RSVP has always supported the indication of errors in Err messages. As discussed above, RFC3473=20 does not change this, nor does RFC4872. As such when RFC4872 uses the=20 phrase "detects the failure" it MUST be read to include receipt of an=20 Err message. If you wish, you can open an editorial errata on this point so that this topic is clarified in a future revision of the standard. > > 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. As written, RFC4872 uses "LSP Failure" to indicate a Switchover Request, and "LSP Locally Failed" to indicate a failure in the data plane. > However, it seems strange not to trigger restoration > procedures on receipt of errors that describe other faults. > This is not precluded (nor required) by the RFC, so an implementation=20 may choose to trigger restoration on any error. > Fourth, some implementations used error code zero for administratively > initiated graceful release of an LSP. Per RFC2205: o Error Code =3D 00: Confirmation This code is reserved for use in the ERROR_SPEC object of a ResvConf message. The Error Value will also be zero. > We see that >=20 http://tools.ietf.org/html/draft-ietf-ccamp-mpls-graceful-shutdown-10#se ction-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." > You are correct that such an error value for this explicit purpose is not defined.=20 Such a value can be defined by submitting an Internet draft with the=20 definition of the value and then bringing the document to the CCAMP=20 working group. In short, the RFC4929 defined process may be followed to get such an error value assigned. > We welcome guidance from CCAMP on these three points. Thank you for > your continued attention. Regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs From wwwrun@core3.amsl.com Fri Jan 22 15:28:25 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B740C28C0D8; Fri, 22 Jan 2010 15:28:25 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100122232825.B740C28C0D8@core3.amsl.com> Date: Fri, 22 Jan 2010 15:28:25 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] Last Call: draft-ietf-ccamp-gmpls-dcsc-channel-ext (Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions) to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 23:28:25 -0000 The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-02-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-dcsc-channel-ext-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17636&rfc_flag=0 From wwwrun@core3.amsl.com Mon Jan 25 08:59:15 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B054A3A6884; Mon, 25 Jan 2010 08:59:15 -0800 (PST) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100125165915.B054A3A6884@core3.amsl.com> Date: Mon, 25 Jan 2010 08:59:15 -0800 (PST) Cc: ccamp mailing list , Internet Architecture Board , ccamp chair , RFC Editor Subject: [CCAMP] Document Action: 'Category: Informational Expires: July 19, 2010 January 20, 2010' to Informational RFC X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 16:59:15 -0000 The IESG has approved the following document: - 'Category: Informational Expires: July 19, 2010 January 20, 2010 ' as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-13.txt Technical Summary MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network. This document provides requirements and protocol mechanisms to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS and its Generalized MPLS (GMPLS) extensions. This document explains usage of existing protocol mechanisms to support a "Graceful Shutdown" operation. No new protocol mechanisms are defined Working Group Summary The document was significantly revised to be in line with draft-ietf-mpls-gmpls-lsp-reroute. Much of the WG discussion focused on this. Once alignment was agreed upon, there was no significant disagreement. Document Quality There are no known implementations or planned implementations of this work. Personnel Lou Berger (lberger@labn.net) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible Area Director. From wwwrun@core3.amsl.com Mon Jan 25 09:06:21 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 20EFC3A67E7; Mon, 25 Jan 2010 09:06:20 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100125170621.20EFC3A67E7@core3.amsl.com> Date: Mon, 25 Jan 2010 09:06:21 -0800 (PST) Cc: ccamp mailing list , Internet Architecture Board , ccamp chair , RFC Editor Subject: [CCAMP] CORRECTED Document Action: 'Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks' to Informational RFC X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 17:06:21 -0000 The IESG has approved the following document: - 'Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks ' as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-13.txt Technical Summary MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network. This document provides requirements and protocol mechanisms to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS and its Generalized MPLS (GMPLS) extensions. This document explains usage of existing protocol mechanisms to support a "Graceful Shutdown" operation. No new protocol mechanisms are defined Working Group Summary The document was significantly revised to be in line with draft-ietf-mpls-gmpls-lsp-reroute. Much of the WG discussion focused on this. Once alignment was agreed upon, there was no significant disagreement. Document Quality There are no known implementations or planned implementations of this work. Personnel Lou Berger (lberger@labn.net) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible Area Director. From db3546@att.com Tue Jan 26 10:46:43 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305AF3A697A for ; Tue, 26 Jan 2010 10:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 md1WwiClrSBQ for ; Tue, 26 Jan 2010 10:46:42 -0800 (PST) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id E48AE3A68D3 for ; Tue, 26 Jan 2010 10:46:41 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-6.tower-161.messagelabs.com!1264531611!24252703!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 14684 invoked from network); 26 Jan 2010 18:46:52 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-6.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Jan 2010 18:46:52 -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 o0QIkjvZ022426; Tue, 26 Jan 2010 13:46:45 -0500 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 o0QIkhuc022397; Tue, 26 Jan 2010 13:46:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jan 2010 13:46:47 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Communication to the OIF on Routing Thread-Index: Acqet+m//8LFXcD4Q6aTJB58X4qV3g== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "Ong, Lyndon" Cc: Ross Callon , CCAMP , kchiu@oiforum.com, Adrian Farrel Subject: [CCAMP] Communication to the OIF on Routing X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 18:46:43 -0000 Dear Lyndon, In your October 22nd communication, you requested consideration of two routing related drafts for CCAMP related to OIF testing. On ASON Routing implementation experience "draft-ong-gmpls-ason-routing-exper-00.txt": This document was presented at November's meeting. While it is re-affirming to hear that your development work and interoperability testing confirmed the routing functionality defined in [OSPF-ASON], your use of different sub-TLVs for the testing does not support the transition of [OSPF-ASON] to standards status. Due to the lack of community interest in testing and deploying ASON routing functionality, [OSPF-ASON] was designated as IETF experimental status. If future OIF testing is based on [OSPF-ASON], the discussion on transition of [OSPF-ASON] to standards status could be revisited. On your request for your defined extensions to be given IETF standards status, we remind you of RFC4929: "The definition and publishing of non-standard extensions by other fora, without IETF review, and outside of the IETF publication process, regardless if rationalized as limited to use among fora vendors, or limited to a particular application, or rationalized as allowing timely demos, has the unfortunate potential to hinder interoperability and increase complexity of the protocol, sows confusion in the industry, and circumvents the Internet standards process that exists to ensure protocol implementability. As described in [RFC4775], non-standard extensions, including experimental values, are not to be portrayed as industrial standards whether by an individual vendor, an industry forum, or a standards body." Specifically of concern, we note in your document, the definition of alternative functionality for existing functionality. In section 3.2.1, a new ISCD sub-TLV for advertising "compact" description of connection availability is defined which is non-compatible with standard GMPLS. And, in section 4.4, new sub-TLV is defined as an alternative to [OSPF-Node] which was used in [OSPF-ASON]. You state as justification (section 4.4): "This tested format is functionally equivalent to the format defined in [OSPF-ASON] but is independent of the function of advertising local addresses of a router for MPLS TE LSPs as defined in [OSPF-NODE]." Are you concerned on the use of a common set of procedures by MPLS and GMPLS such that you believe the need to develop alternatives to ensure independence in the advertising? It would be of benefit to the GMPLS community if you would communicate these concerns so they could be addressed properly before developing your own extensions. We recommend that future OIF testing and related drafts be based on [OSPF-ASON]. This would facilitate the alignment of OIF work with CCAMP produced RFCs. On additional functions for ASON routing "draft-theillaud-gmpls-ason-routing-add-fcts-01.txt": The document was introduced at November's meeting and a discussion thread was initiated on CCAMP's exploder on one of the requested functionalities: link associated local connection type. The example provided in Section 3.1 on the need to distinguish high-order and lower-order VC-3s was discussed and it was concluded the functionality is already supported: http://www.ietf.org/mail-archive/web/ccamp/current/msg10716.html You may want to review RFC4202 where this is described: "A way to handle the case where an interface supports multiple branches of the SDH multiplexing hierarchy, multiple Interface Switching Capability Descriptors would be advertised, one per branch. For example, if an interface supports VC-11 and VC-12 (which are not part of same branch of SDH multiplexing tree), then it could advertise two descriptors, one for each one." Section 3 of RFC4202 additionally provides multiple examples which may be helpful. The other proposed functionality, on layer-scoped link attributes, has not been discussed and we welcome the authors of the draft to initiate discussion on the CCAMP list. In your July 23rd communication, you indicated the need to support NSAP format in the advertisement of node local prefixes. We welcome your members to submit a draft detailing the requested functionality. We also direct you to a related discussion that took place in the context of the L1VPN Working Group on November 9, 2005 as reported in http://www.ietf.org/proceedings/64/l1vpn.html. Specifically: Several questions were discussed: - Is there a requirement to support NSAPs? The mechanisms for embedding NSAP in IPv6 (RFC 1888) is now marked as historic. We could bring this back alive simply by republishing, if we need the function. Question is whether we actually need the function. - A poll of room showed slight interest in supporting NSAPs, and no opposition.=20 Since there is very low cost to supporting this it is easy, but we don't usually do things without specific demand. We encourage your members to participate in IETF's CCAMP email exploders and the development of standards to prevent these misunderstandings in the future. Regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs From db3546@att.com Tue Jan 26 10:52:54 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4837E3A697A for ; Tue, 26 Jan 2010 10:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 K5Y1DeXJ+607 for ; Tue, 26 Jan 2010 10:52:53 -0800 (PST) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 474133A6956 for ; Tue, 26 Jan 2010 10:52:53 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1264531982!31233062!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 3102 invoked from network); 26 Jan 2010 18:53:03 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Jan 2010 18:53: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 o0QIquK9028512; Tue, 26 Jan 2010 13:52:56 -0500 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 o0QIqtVj028503; Tue, 26 Jan 2010 13:52:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jan 2010 13:52:59 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Communication to the OIF on Inverse Multiplexing Thread-Index: AcqeuMf6w68Sntl7QyGtZXbCZnqnZg== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "Ong, Lyndon" Cc: Ross Callon , CCAMP , kchiu@oiforum.com, Adrian Farrel Subject: [CCAMP] Communication to the OIF on Inverse Multiplexing X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 18:52:54 -0000 Dear Lyndon, In your October 22nd communication, you requested consideration of a draft on inverse multiplexing "draft-roch-ccamp-gmpls-inv-mux-00.txt". This document was introduced at November's meeting. During CCAMP's Working Group Last Call discussion of "draft-ietf-ccamp-vcat-lcas", the use cases in draft-roch-ccamp-gmpls-inv-mux-00.txt as compared to the scope of draft-ietf-ccamp-vcat-lcas-08.txt were discussed. The use cases and=20 items raised in draft-roch-ccamp-gmpls-inv-mux as we understand it are=20 as follows: 1. IMG members are (statically) provisioned. 2. Members might be separately administered and policies may=20 prevent signaling control information related to the IMG to be exchanged in the member signaling. 3. Control plane does not allow piggybacking of IMG information onto=20 its own signaling. The use cases represented in 1. and 2. were considered out-of-scope of=20 the CCAMP document. The scope of the CCAMP document is to support only=20 scenarios where all members are signaled using the defined mechanism. CCAMP support for new functionality must be raised within the Working Group. We suggest that further discussion on these use cases=20 take place based on an updated Internet Draft which is based on existing CCAMP work, i.e., draft-ietf-ccamp-vcat-lcas, which has passed last call. With respect to item 3, in the existing CCAMP work, only the VCAT=20 end-points participate in signaling the IMG information, i.e., the=20 intermediate signaling nodes do not participate in the VCAT call setup.=20 If the end points do not support the CCAMP VCAT signaling mechanism,=20 VCAT isn't provided. Again, the scope of the current work is to support only scenarios where all members are signaled using the defined extension. We welcome future contributions defining your requirements in the form=20 of Internet-drafts. Please note that draft-ietf-ccamp-vcat-lcas is a=20 product of the Working Group. As such, the Working Group will be=20 focused on the reuse of this work in any future related work. As always, we encourage you to follow RFC4929's defined process. Regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs From db3546@att.com Tue Jan 26 10:59:30 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37BE3A6990 for ; Tue, 26 Jan 2010 10:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 9LbisnpavH6t for ; Tue, 26 Jan 2010 10:59:29 -0800 (PST) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id CCAE03A698E for ; Tue, 26 Jan 2010 10:59:28 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1264532378!30798956!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 2433 invoked from network); 26 Jan 2010 18:59:38 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Jan 2010 18:59:38 -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 o0QIxWko002641; Tue, 26 Jan 2010 13:59:32 -0500 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 o0QIxTct002630; Tue, 26 Jan 2010 13:59:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jan 2010 13:59:34 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Communication to the OIF on Error Messages Thread-Index: AcqeubLf588ErZUHSOOyX+dIC+mJBA== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: "Ong, Lyndon" Cc: Ross Callon , CCAMP , kchiu@oiforum.com, Adrian Farrel Subject: [CCAMP] Communication to the OIF on Error Messages X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 18:59:30 -0000 Dear Lyndon, In your communication of Oct. 22nd, you asked guidance on the following points. > 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. This is incorrect behavior. Per RFC3473: The Notify message does not replace existing error messages. and Notify messages are most commonly generated at nodes that detect an error that will trigger the generation of a PathErr or ResvErr message. The remainder of the procedures discuss the cases where Notify is=20 generated *in addition* to a PathErr or ResvErr. We believe the RFC is sufficiently clear on this point. > 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. Here too implementations must process both Err messages and Notify=20 messages. RFC4872 is an extension to RSVP-TE. RSVP has always supported the indication of errors in Err messages. As discussed above, RFC3473=20 does not change this, nor does RFC4872. As such when RFC4872 uses the=20 phrase "detects the failure" it MUST be read to include receipt of an=20 Err message. If you wish, you can open an editorial errata on this point so that this topic is clarified in a future revision of the standard. > > 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. As written, RFC4872 uses "LSP Failure" to indicate a Switchover Request, and "LSP Locally Failed" to indicate a failure in the data plane. > However, it seems strange not to trigger restoration > procedures on receipt of errors that describe other faults. > This is not precluded (nor required) by the RFC, so an implementation=20 may choose to trigger restoration on any error. > Fourth, some implementations used error code zero for administratively > initiated graceful release of an LSP. Per RFC2205: o Error Code =3D 00: Confirmation This code is reserved for use in the ERROR_SPEC object of a ResvConf message. The Error Value will also be zero. > We see that >=20 http://tools.ietf.org/html/draft-ietf-ccamp-mpls-graceful-shutdown-10#se ction-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." > You are correct that such an error value for this explicit purpose is not defined.=20 Such a value can be defined by submitting an Internet draft with the=20 definition of the value and then bringing the document to the CCAMP=20 working group. In short, the RFC4929 defined process may be followed to get such an error value assigned. > We welcome guidance from CCAMP on these three points. Thank you for > your continued attention. Regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs From ldunbar@huawei.com Tue Jan 26 16:31:12 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE3093A6768; Tue, 26 Jan 2010 16:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PX4VqPrpbd4l; Tue, 26 Jan 2010 16:31:12 -0800 (PST) Received: from s-utl01-sjpop.stsn.net (s-utl01-sjpop.stsn.net [72.254.0.201]) by core3.amsl.com (Postfix) with SMTP id 329083A63C9; Tue, 26 Jan 2010 16:31:12 -0800 (PST) Received: from s-utl01-sjpop.stsn.net ([127.0.0.1]) by s-utl01-sjpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2010012616312431467 ; Tue, 26 Jan 2010 16:31:24 -0800 Received: from L735042 ([10.0.103.99]) by s-utl01-sjpop.stsn.net; Tue, 26 Jan 2010 16:31:23 -0800 From: "Linda Dunbar" To: "'Loa Andersson'" , , , , References: <4B4DFC51.8050301@pi.nu> Date: Tue, 26 Jan 2010 18:31:15 -0600 Message-ID: <007c01ca9ee8$10817000$d867000a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcqUclEF3wbLlNyvSOKn9kGSlOPK/AKdbEew X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4B4DFC51.8050301@pi.nu> Subject: Re: [CCAMP] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 00:31:13 -0000 Support. Linda Dunbar -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Wednesday, January 13, 2010 11:01 AM To: mpls-tp@ietf.org; mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: [CCAMP] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document All, this is to start a two week poll on making http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 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. Please note that it is a conscious decision by the wg chair to poll the linear-protection document prior to the ring-protection document, since we want to make room for separated discussions on the two documents. The poll ends Friday juanuary 29, 2010. /Loa -- _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From mach@huawei.com Thu Jan 28 04:57:14 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80C493A6782; Thu, 28 Jan 2010 04:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfPoQNhuWa1B; Thu, 28 Jan 2010 04:57:13 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 97B333A672E; Thu, 28 Jan 2010 04:57:13 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWY00MATJZTEO@szxga02-in.huawei.com>; Thu, 28 Jan 2010 20:57:30 +0800 (CST) Received: from m55527c ([10.111.12.235]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWY00E4KJZT2C@szxga02-in.huawei.com>; Thu, 28 Jan 2010 20:57:29 +0800 (CST) Date: Thu, 28 Jan 2010 20:57:29 +0800 From: Mach Chen In-reply-to: <4B4DFC51.8050301@pi.nu> To: Loa Andersson , mpls-tp@ietf.org, mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org Message-id: <387E4A6CAB424C53ADDF9C59DAD04F43@m55527c> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <4B4DFC51.8050301@pi.nu> Subject: Re: [CCAMP] [mpls] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2010 12:57:14 -0000 yes/support Mach -------------------------------------------------- From: "Loa Andersson" Sent: Thursday, January 14, 2010 1:01 AM To: ; ; ; Subject: [mpls] poll on making draft-weingarten-mpls-tp-linear-protection an mpls wg document > All, > > this is to start a two week poll on making > > http://tools.ietf.org/html/draft-weingarten-mpls-tp-linear-protection-05 > > 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. > > Please note that it is a conscious decision by the wg chair to poll > the linear-protection document prior to the ring-protection > document, since we want to make room for separated discussions on > the two documents. > > The poll ends Friday juanuary 29, 2010. > > /Loa > -- > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From root@core3.amsl.com Thu Jan 28 22:30:30 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1FFF73A6974; Thu, 28 Jan 2010 22:30:06 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100129063013.1FFF73A6974@core3.amsl.com> Date: Thu, 28 Jan 2010 22:30:06 -0800 (PST) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-oam-configuration-fwk-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, 29 Jan 2010 06:30:30 -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-03.txt Pages : 22 Date : 2010-01-28 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-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-oam-configuration-fwk-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-01-28222042.I-D@ietf.org> --NextPart-- From Attila.Takacs@ericsson.com Thu Jan 28 22:47:42 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38B0B3A6942 for ; Thu, 28 Jan 2010 22:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIN6lrXQGD9b for ; Thu, 28 Jan 2010 22:47:39 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 79D6C3A6452 for ; Thu, 28 Jan 2010 22:47:39 -0800 (PST) X-AuditID: c1b4fb24-b7c64ae000005cb7-fa-4b62849e0822 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 2E.B8.23735.E94826B4; Fri, 29 Jan 2010 07:47:59 +0100 (CET) Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.1.68]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 29 Jan 2010 07:47:58 +0100 From: Attila Takacs To: Lou Berger , "DEBORAH A, ATTLABS BRUNGARD" , "ccamp@ietf.org" Date: Fri, 29 Jan 2010 07:47:07 +0100 Thread-Topic: Updated GMPLS based OAM configuration documents Thread-Index: Acqgrt/aQSY8XdYrS3Shf3Wmq6MzAg== Message-ID: <79F41BA1E9BF3C489375521EF8DDE23C12050D4AB6@ESESSCMS0355.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Subject: [CCAMP] Updated GMPLS based OAM configuration documents X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 06:47:42 -0000 Hi all, We updated the GMPLS based OAM configuration framework document (draft-ietf= -ccamp-oam-configuration-fwk-02). The major changes are the following: *) Removed the discussion on segment/tandem connection monitoring, and so f= ixed the scope of the document to the configuration of e2e OAM (in terms of= the LSP).=20 *) We added detailed text on the steps of configuring/enabling OAM entities= /functions relative to Path/Resv message exchanges (Section 3). *) Since there were concerns about the size of the OAM function flags field= , the flags are now moved to a dedicated sub-TLV (Section 4.2.1) allowing e= xtensibility. We will submit a new document covering the configuration of segment/TCM mon= itoring to facilitate the discussion on the pros/cons of possible alternati= ves (like the scaling issues raised in Hiroshima, and the points sent by Di= mitri to the list earlier). The authors of draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext and draft-bellagamb= a-ccamp-rsvp-te-mpls-tp-oam-ext also updated their documents to be aligned = with the fwk and with each other. We think that the drafts are now in a goo= d shape to reinitiate the poll to became WG documents. It would be good if = we could poll both documents at the same time, if the chairs and the group = agree. Thanks and best regards, Attila= From danli@huawei.com Sat Jan 30 00:42:24 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00CD73A6407 for ; Sat, 30 Jan 2010 00:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, 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 wWNVK46Wk9om for ; Sat, 30 Jan 2010 00:42:22 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 928D83A6358 for ; Sat, 30 Jan 2010 00:42:20 -0800 (PST) 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 <0KX100GT6XIXP4@szxga04-in.huawei.com> for ccamp@ietf.org; Sat, 30 Jan 2010 16:42:33 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KX100DNXXIX9Q@szxga04-in.huawei.com> for ccamp@ietf.org; Sat, 30 Jan 2010 16:42:33 +0800 (CST) Received: from l37133a ([10.70.77.58]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KX10069MXIX5R@szxml06-in.huawei.com> for ccamp@ietf.org; Sat, 30 Jan 2010 16:42:33 +0800 (CST) Date: Sat, 30 Jan 2010 16:42:33 +0800 From: Dan Li To: ccamp@ietf.org Message-id: <005e01caa188$2a55f120$3a4d460a@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_EvvVyOkcfwUfIecrshVhIQ)" X-Priority: 3 X-MSMail-priority: Normal References: <4AD74572.2070508@labn.net> <00d501ca99b0$e7d043c0$3a4d460a@china.huawei.com> Subject: Re: [CCAMP] Remain issue with lambda-label 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: Sat, 30 Jan 2010 08:42:24 -0000 This is a multi-part message in MIME format. --Boundary_(ID_EvvVyOkcfwUfIecrshVhIQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi all, We have received a comment on this issue, and would like to introduce a new "Identifier" field in the label format by replacing the reserved field. This field would be under the control of a particular node and could be assigned as desired by the node. To allow for remote reference (e.g., via ERO) the special value of 0 (zero) could be used to indicate that any node resource could be used by the node. There is no requirement that a node used a value other than 0, e.g., in the case where fixed lasers are used or ID values aren't needed by the node. Please let us know if you would agree on this suggestion. Thanks, Authors ----- Original Message ----- From: Dan Li To: ccamp@ietf.org Sent: Wednesday, January 20, 2010 5:14 PM Subject: [CCAMP] Remain issue with lambda-label draft Hi all, On behalf of the authors of lambda-label draft, I would like to continue the discussion on this draft. Please provide your proposal on the mailing list. BTW, the latest version of lambda-label draft can be found at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g-694-lambda-labels-05 Thanks, Authors ----- Original Message ----- From: Lou Berger To: draft-ietf-ccamp-gmpls-g-694-lambda-labels@tools.ietf.org ; ccamp@ietf.org Sent: Thursday, October 15, 2009 11:53 PM Subject: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique resource identification 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 ------------------------------------------------------------------------------ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --Boundary_(ID_EvvVyOkcfwUfIecrshVhIQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi all,
 
We have received a comment on this issue, and would like to introduce a new "Identifier" field in the label format by replacing the reserved field. This field would be under the control of a particular node and could be assigned as desired by the node.  To allow for remote reference (e.g., via ERO) the special value of 0 (zero) could be used to indicate that any node resource could be used by the node. There is no requirement that a node used a value other than 0, e.g., in the case where fixed lasers are used or ID values aren't needed by the node.
 
Please let us know if you would agree on this suggestion.
 
Thanks,
 
Authors
 

----- Original Message -----
From: Dan Li
Sent: Wednesday, January 20, 2010 5:14 PM
Subject: [CCAMP] Remain issue with lambda-label draft

Hi all,
 
On behalf of the authors of lambda-label draft, I would like to continue the discussion on this draft.
Please provide your proposal on the mailing list.
 
BTW, the latest version of lambda-label draft can be found at:
 
Thanks,
 
Authors
 
 
----- Original Message -----
From: Lou Berger
Sent: Thursday, October 15, 2009 11:53 PM
Subject: [CCAMP] draft-ietf-ccamp-gmpls-g-694-lambda-labels and unique resource identification

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

_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
--Boundary_(ID_EvvVyOkcfwUfIecrshVhIQ)--