From root@core3.amsl.com Tue Sep 1 08:45:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6D54D3A6AD6; Tue, 1 Sep 2009 08:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090901154501.6D54D3A6AD6@core3.amsl.com> Date: Tue, 1 Sep 2009 08:45:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-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: Tue, 01 Sep 2009 15:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework Author(s) : D. Fedyk, et al. Filename : draft-ietf-ccamp-gmpls-ethernet-arch-05.txt Pages : 21 Date : 2009-09-01 There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH), Time-Division Multiplex (TDM) and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized GMPLS based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed and this document provides a framework for these extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-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-gmpls-ethernet-arch-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-01083642.I-D@ietf.org> --NextPart-- From dbrungard@att.com Wed Sep 2 10:19:38 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35033A6BF8 for ; Wed, 2 Sep 2009 10:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.317 X-Spam-Level: X-Spam-Status: No, score=-106.317 tagged_above=-999 required=5 tests=[AWL=0.283, 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 75zlf5I-E6y5 for ; Wed, 2 Sep 2009 10:19:37 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 51D6D3A6BE3 for ; Wed, 2 Sep 2009 10:19:37 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-2.tower-167.messagelabs.com!1251905447!11635558!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 31521 invoked from network); 2 Sep 2009 15:30:48 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-2.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2009 15:30:48 -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 n82FUmum013278 for ; Wed, 2 Sep 2009 11:30:48 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n82FUiB5013264 for ; Wed, 2 Sep 2009 11:30:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Sep 2009 11:30:42 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Liaison to ITU SG15 Q6 on G694 Labels Thread-Index: Acor4lVJXq5FuW08Sfyl440tcHy7ww== From: "BRUNGARD, DEBORAH A, ATTLABS" To: Subject: [CCAMP] Proposed Liaison to ITU SG15 Q6 on G694 Labels 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, 02 Sep 2009 17:19:38 -0000 CCAMP, As we agreed, we need to send a liaison to ITU's SG15 Q6 on our CCAMP document, "Generalized Labels for G.694 Lambda-Switching Capable Label Switching Routers". Checking the document, I noted it will expire before the ITU meeting. I also noted that it predated Q6's decision to include the encoding information in G.697 so it doesn't reference G.697. Suggest we update the document to reference G.697 (and this will refresh the document): - Section 3, last sentence: "and should be followed as a wavelength label."-> "and should be followed as a wavelength label which is based on the encodings in [G.697]." - Section 4, add reference to G.697 for grid and channel spacing. - Informative References include G.697, for the date, we can say "proposed" for now and then update it later. As we need to include an updated link to the document for the liaison, can the authors please update the document? Let us know if any comments on this proposal. Deborah and Lou -----------------Proposed Liaison-------------------- From: IETF CCAMP WG To: ITU-T Study Group 15 Question 6 Peter Stassar Pete Anslow Ross Callon Adrian Farrel Cc: Scott Bradner Francesco Montalti Title: ITU-T Recommendation G.697 Parameter Encoding Purpose: For Action =20 The CCAMP Working Group of IETF thanks you for your time in meeting with members of CCAMP to discuss our WSON work at your Sunnyvale meeting. We would like to request your review of the CCAMP document "Generalized Labels for G.694 Lambda-Switching Capable Label Switching Routers": http://www.ietf.org/id/draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.txt This document was updated based on our discussion at the Sunnyvale meeting on your proposed changes to G.697 (Appendix V on Parameter encoding).=20 We would appreciate your review to ensure our understanding is correct on your proposed Wavelength ID field encoding. Would you please inform us if this proposed Appendix has been included in the revised G.697 planned for consent at this September's SG15 Plenary meeting? Best Regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs From vishwas.ietf@gmail.com Wed Sep 2 11:03:40 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B521F3A6947 for ; Wed, 2 Sep 2009 11:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2DYcTJEeuxb for ; Wed, 2 Sep 2009 11:03:39 -0700 (PDT) Received: from mail-yw0-f199.google.com (mail-yw0-f199.google.com [209.85.211.199]) by core3.amsl.com (Postfix) with ESMTP id C0B703A682F for ; Wed, 2 Sep 2009 11:03:39 -0700 (PDT) Received: by ywh37 with SMTP id 37so210945ywh.17 for ; Wed, 02 Sep 2009 11:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=o1EmYqpmAsz8lnj1TaiooGKwdaCffhQWx5adviTYP+8=; b=gjYQnTXR5nDkQ7l5u3xwhn1v2GpmKm5nWf9EEZ352GwEAOaV9SmB+nfNTP1Qcu9zPE jZRCGLkwWvXtrv0VYrw/oxdt3Qr0ZnpYoXeu7r8PQw4kyxku3Q3VYAePcz4JYjkfGvL0 QQdxfK/DZBtGGLx7Xr3jpTOM57Xc7RXFwqptM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=cB2FaQhUfnxm6kqNJ0xXpSonBJgjATjibhk0vvaMrkdaecVpbeOL4yPkhP/ZB/gtCw GZZ4nd2YaE1k1S7810XM1+XNHmK9BGj/K6xLGziXKwl9O6yoUokwoU+2fTH0YffQhE3D ET7FFYkGkjlZeNi4w2KH9u97rbL+uWOWfD9tw= MIME-Version: 1.0 Received: by 10.151.87.21 with SMTP id p21mr14411277ybl.57.1251914121400; Wed, 02 Sep 2009 10:55:21 -0700 (PDT) Date: Wed, 2 Sep 2009 10:55:21 -0700 Message-ID: <77ead0ec0909021055r61d62abbg3c8bb5c203ec3aa5@mail.gmail.com> From: Vishwas Manral To: ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [CCAMP] LMP MIB 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, 02 Sep 2009 18:03:40 -0000 Hi, I find the LMP MIB does not seem to take care of the case of "LMP adjacency" at all. It seems it has been designed to work in the case where there is only a single control channel between a pair of nodes. I do not find a table for that in the MIB. An "LMP adjacency" is formed between two nodes when at least one bi- directional control channel is established between them. Multiple control channels may be active simultaneously for each adjacency; control channel parameters, however, MUST be individually negotiated for each control channel. I see a lot of counters in the counter table based on the Control Channel basis, actually are adjacency level counters, which are not. Even though we are allowing fast keepalives, we are having counter32 and not counter64, even for Hellos. Thanks, Vishwas From vishwas.ietf@gmail.com Wed Sep 2 12:04:44 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 764AF3A6F37 for ; Wed, 2 Sep 2009 12:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 z-BtsPBaVQKL for ; Wed, 2 Sep 2009 12:04:43 -0700 (PDT) Received: from mail-yw0-f199.google.com (mail-yw0-f199.google.com [209.85.211.199]) by core3.amsl.com (Postfix) with ESMTP id A9F0B28C46A for ; Wed, 2 Sep 2009 12:02:38 -0700 (PDT) Received: by ywh37 with SMTP id 37so284871ywh.17 for ; Wed, 02 Sep 2009 12:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=np+HPPLkkJsSEOXTaIcpIlDcU5rjmaXm/yEyW5I0XQw=; b=rI1G9IycInu6K7LEDRundo+5o6VZWUtQLxQ2naGaeUcQuM2aO4TZhCPJEk5+rZ6tjb xcfY5BAlLgOHg2Abh6fhJ/GExJVm4TZRE6cMdtvfWX+M+jEIA19XGyAsfjrgMh2Vqtoh Pk4S92vxI6QmQJRF+DBqyMDb9INGj2Y/MHlJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=h3nmZl/GZIG+7K72XfFM9+pKhcqxn4M7MsiJS7GnFY30rVA6unvJ/Xw5kL+CV5CViM ooQrHZyyM/JD+C8UpwbBWS9ii7rTflZXUOGRLxFWW11+69dFCfJ5GQP350fU/1QZULS7 QhBkypfELvK9QtP7Vx8d6vdYe2E0ea/mNEdsM= MIME-Version: 1.0 Received: by 10.150.163.10 with SMTP id l10mr13101878ybe.223.1251915050083; Wed, 02 Sep 2009 11:10:50 -0700 (PDT) Date: Wed, 2 Sep 2009 11:10:50 -0700 Message-ID: <77ead0ec0909021110p3cc7c215x7f388241724d42bf@mail.gmail.com> From: Vishwas Manral To: ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [CCAMP] LMP MIB 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, 02 Sep 2009 19:04:44 -0000 Hi, The LMP spec allows the value of 0 for the Hello Interval. The Textual convention in the LMP MIB used by the lmpCcHelloInterval object LmpInterval is defined as LmpInterval ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The interval delay, in milliseconds." SYNTAX Unsigned32 (1..65535) where a value of 0 cannot be set. I think the textual convention should be changed to LmpInterval ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The interval delay, in milliseconds." SYNTAX Unsigned32 (0..65535) Thanks, Vishwas From lberger@labn.net Thu Sep 3 06:24:20 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C183A6C8A for ; Thu, 3 Sep 2009 06:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.013 X-Spam-Level: X-Spam-Status: No, score=-2.013 tagged_above=-999 required=5 tests=[AWL=0.252, 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 zZ6S3USMOKdy for ; Thu, 3 Sep 2009 06:24:19 -0700 (PDT) Received: from outbound-mail-138.bluehost.com (outbound-mail-138.bluehost.com [67.222.39.28]) by core3.amsl.com (Postfix) with SMTP id 373513A684A for ; Thu, 3 Sep 2009 06:24:19 -0700 (PDT) Received: (qmail 12884 invoked by uid 0); 3 Sep 2009 13:22:52 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy4.bluehost.com with SMTP; 3 Sep 2009 13:22:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=rxJubB19mAF/J5IFiFKl2YGFVBYP4pN3eRs7fab49n5nal6+B3OLQa7w4Pg3d1nE8Qsis0fTJgZHUkCCui/Ik9lGwZI/Z0t8cv8JtM9T6m867oLLnZkEqBFaREEtK6p+; 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 1MjCH5-0005SZ-PC for ccamp@ietf.org; Thu, 03 Sep 2009 07:22:52 -0600 Message-ID: <4A9FC32E.6080607@labn.net> Date: Thu, 03 Sep 2009 09:22:54 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: ccamp@ietf.org References: <4A8B513F.3010908@labn.net> In-Reply-To: <4A8B513F.3010908@labn.net> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-pc-spc-rsvpte-ext 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, 03 Sep 2009 13:24:20 -0000 This LC is complete. I don't believe any additional comments were received so no update is anticipated. The next step in the process is for the chairs to issue a formal publication request. Authors, If you have any additional updates please submit or let me know that a new rev is coming as soon as possible. Lou On 8/18/2009 9:11 PM, Lou Berger wrote: > This email begins a two week working group last call on > draft-ietf-ccamp-pc-spc-rsvpte-ext-03.txt > > http://tools.ietf.org/html/draft-ietf-ccamp-pc-spc-rsvpte-ext-03 > > Please send your comments to the list or the authors before the last > call closes on September 1, 2009. > > As discussed in Stockholm, we are holding an additional last call on > this draft due to the changes made as a result of the previous Last > Call. (For slides from Stockholm see > http://tools.ietf.org/agenda/75/slides/ccamp-4.ppt) > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From lberger@labn.net Thu Sep 3 06:30:11 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732963A6B04 for ; Thu, 3 Sep 2009 06:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.245, 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 aRfFqRn+b+-Q for ; Thu, 3 Sep 2009 06:30:10 -0700 (PDT) Received: from outbound-mail-150.bluehost.com (outbound-mail-150.bluehost.com [67.222.38.40]) by core3.amsl.com (Postfix) with SMTP id 62A293A69A7 for ; Thu, 3 Sep 2009 06:30:10 -0700 (PDT) Received: (qmail 16800 invoked by uid 0); 3 Sep 2009 13:22:45 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy5.bluehost.com with SMTP; 3 Sep 2009 13:22:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=ihXfBWC1qDfnOrv5IJ56JAFIZbsNXdb7U8Q4ZzAfu828G2VGAn2a/jzbyhvOvdO+3ZVBWv2P2a21CDX8NScLv7D4vY/0772B8S7T2Njet5art80ILp5okzr78PUbOcHI; 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 1MjCGz-0005Qt-C3 for ccamp@ietf.org; Thu, 03 Sep 2009 07:22:45 -0600 Message-ID: <4A9FC327.3030701@labn.net> Date: Thu, 03 Sep 2009 09:22:47 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: ccamp@ietf.org References: <4A8B513C.2040308@labn.net> In-Reply-To: <4A8B513C.2040308@labn.net> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-confirm-data-channel-status 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, 03 Sep 2009 13:30:11 -0000 This LC is complete. I don't believe any additional comments were received so no update is anticipated. The next step in the process is for the chairs to issue a formal publication request. Authors, If you have any additional updates please submit or let me know that a new rev is coming as soon as possible. Lou On 8/18/2009 9:11 PM, Lou Berger wrote: > This email begins a two week working group last call on > draft-ietf-ccamp-confirm-data-channel-status-06.txt > > http://tools.ietf.org/html/draft-ietf-ccamp-confirm-data-channel-status-06 > > Please send your comments to the list or the authors before the last > call closes on September 1, 2009. > > As discussed in Stockholm, we are holding an additional last call on > this draft due to the changes made as a result of the previous Last > Call. (For slides from Stockholm see > http://tools.ietf.org/agenda/75/slides/ccamp-3.ppt) > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From daniele.ceccarelli@ericsson.com Thu Sep 3 06:35:42 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 943DE3A6817 for ; Thu, 3 Sep 2009 06:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.663 X-Spam-Level: X-Spam-Status: No, score=-4.663 tagged_above=-999 required=5 tests=[AWL=1.586, 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 NpvAK1IDVGBj for ; Thu, 3 Sep 2009 06:35:41 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 49B6A3A6781 for ; Thu, 3 Sep 2009 06:35:40 -0700 (PDT) X-AuditID: c1b4fb3e-b7c00ae0000007bf-36-4a9fc60b25e7 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id D8.A9.01983.B06CF9A4; Thu, 3 Sep 2009 15:35:07 +0200 (CEST) Received: from EITRMMW021.eemea.ericsson.se ([141.137.48.176]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Sep 2009 15:35:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Sep 2009 15:34:58 +0200 Message-ID: In-Reply-To: <4A9FC32E.6080607@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] 2nd Working group lastcall: draft-ietf-ccamp-pc-spc-rsvpte-ext Thread-Index: AcosmeUt/9O2GDBmTna6ECLKCoQPZgAATofg References: <4A8B513F.3010908@labn.net> <4A9FC32E.6080607@labn.net> From: "Daniele Ceccarelli" To: "Lou Berger" X-OriginalArrivalTime: 03 Sep 2009 13:35:00.0272 (UTC) FILETIME=[55B15B00:01CA2C9B] X-Brightmail-Tracker: AAAAAA== Cc: ccamp@ietf.org Subject: Re: [CCAMP] 2nd Working group lastcall: draft-ietf-ccamp-pc-spc-rsvpte-ext 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, 03 Sep 2009 13:35:42 -0000 Hi Lou, no additional update from the authors. Many thanks Daniele -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Lou Berger Sent: gioved=EC 3 settembre 2009 15.23 To: ccamp@ietf.org Subject: Re: [CCAMP] 2nd Working group lastcall: = draft-ietf-ccamp-pc-spc-rsvpte-ext This LC is complete. I don't believe any additional comments were = received so no update is anticipated. The next step in the process is = for the chairs to issue a formal publication request. Authors, If you have any additional updates please submit or let me know that a = new rev is coming as soon as possible. Lou On 8/18/2009 9:11 PM, Lou Berger wrote: > This email begins a two week working group last call on=20 > draft-ietf-ccamp-pc-spc-rsvpte-ext-03.txt >=20 > http://tools.ietf.org/html/draft-ietf-ccamp-pc-spc-rsvpte-ext-03 >=20 > Please send your comments to the list or the authors before the last=20 > call closes on September 1, 2009. >=20 > As discussed in Stockholm, we are holding an additional last call on=20 > this draft due to the changes made as a result of the previous Last=20 > Call. (For slides from Stockholm see > http://tools.ietf.org/agenda/75/slides/ccamp-4.ppt) > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 >=20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From danli@huawei.com Thu Sep 3 07:25:55 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4AFD28C249 for ; Thu, 3 Sep 2009 07:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2zSivnMr56w for ; Thu, 3 Sep 2009 07:25:54 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 5338B28C208 for ; Thu, 3 Sep 2009 07:25:54 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPE00IDYG1V1I@usaga01-in.huawei.com> for ccamp@ietf.org; Thu, 03 Sep 2009 07:25:08 -0700 (PDT) Received: from dan ([121.34.181.86]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPE00DVVG1TZI@usaga01-in.huawei.com> for ccamp@ietf.org; Thu, 03 Sep 2009 07:25:07 -0700 (PDT) Date: Thu, 03 Sep 2009 22:24:44 +0800 From: Dan Li To: Lou Berger , ccamp@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4A8B513C.2040308@labn.net> <4A9FC327.3030701@labn.net> Subject: Re: [CCAMP] 2nd Working group last call:draft-ietf-ccamp-confirm-data-channel-status 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, 03 Sep 2009 14:25:55 -0000 No additional update from the authors. Thanks, Dan ----- Original Message ----- From: "Lou Berger" To: Sent: Thursday, September 03, 2009 9:22 PM Subject: Re: [CCAMP] 2nd Working group last call:draft-ietf-ccamp-confirm-data-channel-status > This LC is complete. I don't believe any additional comments were > received so no update is anticipated. The next step in the process is > for the chairs to issue a formal publication request. > > Authors, > If you have any additional updates please submit or let me know that a > new rev is coming as soon as possible. > > Lou > > On 8/18/2009 9:11 PM, Lou Berger wrote: >> This email begins a two week working group last call on >> draft-ietf-ccamp-confirm-data-channel-status-06.txt >> >> http://tools.ietf.org/html/draft-ietf-ccamp-confirm-data-channel-status-06 >> >> Please send your comments to the list or the authors before the last >> call closes on September 1, 2009. >> >> As discussed in Stockholm, we are holding an additional last call on >> this draft due to the changes made as a result of the previous Last >> Call. (For slides from Stockholm see >> http://tools.ietf.org/agenda/75/slides/ccamp-3.ppt) >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From root@core3.amsl.com Thu Sep 3 17:45:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 62BDE3A683E; Thu, 3 Sep 2009 17:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090904004501.62BDE3A683E@core3.amsl.com> Date: Thu, 3 Sep 2009 17:45:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-confirm-data-channel-status-07.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 00:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Data Channel Status Confirmation Extensions for the Link Management Protocol Author(s) : D. Li, et al. Filename : draft-ietf-ccamp-confirm-data-channel-status-07.txt Pages : 16 Date : 2009-09-03 This document defines simple additions 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. As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. Li Expires March 2010 [page 1] draft-ietf-ccamp-confirm-data-channel-status-07.txt September 2009 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-confirm-data-channel-status-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-confirm-data-channel-status-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-03173828.I-D@ietf.org> --NextPart-- From lberger@labn.net Thu Sep 3 18:11:22 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6324F3A69EF for ; Thu, 3 Sep 2009 18:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=0.220, 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 ZxENEKIgIm7x for ; Thu, 3 Sep 2009 18:11:21 -0700 (PDT) Received: from outbound-mail-113.bluehost.com (outbound-mail-113.bluehost.com [69.89.24.3]) by core3.amsl.com (Postfix) with SMTP id 104C23A681E for ; Thu, 3 Sep 2009 18:11:21 -0700 (PDT) Received: (qmail 29324 invoked by uid 0); 4 Sep 2009 01:09:07 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy3.bluehost.com with SMTP; 4 Sep 2009 01:09:07 -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=0Se0wSCzUEJhJSP+UT1EtdrXX/h0UPDJLp6R4ZqCn91aXvoiggAGKiopT3lh/Z18kiKLr9q+D0ZgSDSvOzhSxnR5k4AufSTisjYUU+u0VWRM1LASAt1JEaN4z4KdlTM0; 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 1MjNIZ-0006at-67; Thu, 03 Sep 2009 19:09:07 -0600 Message-ID: <4AA068B5.8020105@labn.net> Date: Thu, 03 Sep 2009 21:09:09 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Adrian Farrel X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org, iesg-secretary@ietf.org Subject: [CCAMP] Please publish: draft-ietf-ccamp-confirm-data-channel-status-07.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 01:11:22 -0000 Proto-write-up for: draft-ietf-ccamp-confirm-data-channel-status-07.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? Yes. The document has idenitifed a basic issue in LMP with respect to backward compatibility. In particular, LMP does not have a basic mechanism to allow an LMP implementation to determine when a neighbor supports new/extended functionality. We have agreed that as this is a basic LMP issue it should not be fixed in this document, but rather a future standalone document. Current authors have expressed interes in bringing a draft to the WG on this topic. > 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. > If such normative references exist, what is the > strategy for their completion? N/A. > Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. No downward references. > >(1.i) Has the Document Shepherd verified that the document's IANA > Considerations section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process, has the Document > Shepherd conferred with the Responsible Area Director so that > the IESG can appoint the needed Expert during IESG Evaluation? 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 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 > Was there anything in the WG process that is worth noting? > For example, was there controversy about particular points > or were there decisions where the consensus was > particularly rough? This document received adequate attention and discussion 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 > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type, or other Expert Review, > what was its course (briefly)? In the case of a Media Type > Review, on what date was the request posted? > There have been no public statements related to intent to implement, but it is expected that some/all of the primary Authors plan to implement. > Personnel > Who is the Document Shepherd for this document? Lou Berger. > Who is the > Responsible Area Director? Adrian Farrel > If the document requires IANA > experts(s), insert 'The IANA Expert(s) for the registries > in this document are .' > From dbrungard@att.com Fri Sep 4 07:16:02 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31853A6A31 for ; Fri, 4 Sep 2009 07:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.411 X-Spam-Level: X-Spam-Status: No, score=-106.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 Je-iI8OE1qqj for ; Fri, 4 Sep 2009 07:16:01 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id A35B43A6A2F for ; Fri, 4 Sep 2009 07:16:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-3.tower-167.messagelabs.com!1252073752!13391724!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 31466 invoked from network); 4 Sep 2009 14:15:53 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 4 Sep 2009 14:15:53 -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 n84EFrMh026527 for ; Fri, 4 Sep 2009 10:15:53 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n84EFn8Y026494 for ; Fri, 4 Sep 2009 10:15:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Sep 2009 10:15:46 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Liaison to ITU SG15 Q6, Q12, and Q14 on WSON Impairments Thread-Index: AcotajJwLzHgQ3siTeujCLjYQVrJwQ== From: "BRUNGARD, DEBORAH A, ATTLABS" To: Subject: [CCAMP] Proposed Liaison to ITU SG15 Q6, Q12, and Q14 on WSON Impairments 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, 04 Sep 2009 14:16:02 -0000 CCAMP, As we agreed, we need to send a liaison to ITU's SG15 Q6, Q12, and Q14, = informing them of our CCAMP document, "A Framework for the Control of = Wavelength Switched Optical Networks (WSON) with Impairments".=20 This is in response to the ITU liaison: https://datatracker.ietf.org/liaison/479/ Note, the link below in the liaison points to the ITU link. The link for = CCAMP is: http://www.ccamp.labn.net/old_ccamp/www.olddog.co.uk/download/WD6-38.doc Let us know if any comments on this proposal. Deborah and Lou -----------------Proposed Liaison-------------------- From: IETF CCAMP WG To: ITU-T Study Group 15 Question 6, Question 12, and Question 14 Peter Stassar Pete Anslow Malcolm Betts Hing-Kam Lam Ross Callon Adrian Farrel Cc: Patrik F=E4ltstr=F6m=20 Francesco Montalti Stephen Trowbridge Title: WSON Impairment Work in CCAMP Purpose: For Information =20 The CCAMP Working Group of IETF thanks Question 12 for their liaison = from the September 2008 meeting informing of their initiation of work to = be done in cooperation with Question 6 on developing a network model for = WSON which will include optical impairments. We would like to inform you = of our progress in this area as documented in the CCAMP document "A = Framework for the Control of Wavelength Switched Optical Networks (WSON) = with Impairments": http://www.ietf.org/id/draft-ietf-ccamp-wson-impairments-00.txt This document provides a framework for GMPLS protocols and mechanisms to = support impairment aware routing and wavelength assignment. The = deployment scenarios are based on the categories discussed at Question = 6's Sunnyvale meeting: = http://ifa.itu.int/t/2009/sg15/exchange/wp2/q6/Meetings/2009-03-Sunnyvale= /Contributions/WD6-38.doc We would appreciate your consideration of this document in your work and = would you please inform us of the scope of your work and the timelines. = For CCAMP's impairment work, CCAMP is focused on scenarios where = approximated impairment estimation using ITU-T defined parameters and = approximation techniques [G.680] may be used. The objective of CCAMP = work is to distribute the information which is needed to allow path = computation and signaling of new paths. We would appreciate your input = on the parameter information which is needed to be distributed by either = a control plane or Path Computation Element (PCE) and its properties so = as to understand the control plane distribution requirements. In = addition, we would appreciate your perspective on control plane modeling = and implications with regard to ITU-T's G.872 OTN aspects e.g. OTN = multi-layers (OTS, OMS, OCh), regenerators, and o/e/o (OCh/OTU/ODU). Best Regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs From root@core3.amsl.com Mon Sep 7 23:15:02 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1BD963A67E6; Mon, 7 Sep 2009 23:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090908061502.1BD963A67E6@core3.amsl.com> Date: Mon, 7 Sep 2009 23:15:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-08.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 06: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 : Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks Author(s) : W. Sun, et al. Filename : draft-ietf-ccamp-lsp-dppm-08.txt Pages : 49 Date : 2009-09-07 Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. Dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can depict the features of GMPLS networks in LSP dynamic provisioning. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-lsp-dppm-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-07230311.I-D@ietf.org> --NextPart-- From sunwq@MIT.EDU Mon Sep 7 23:26:26 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6433A6926; Mon, 7 Sep 2009 23:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvEzfqUB7V7u; Mon, 7 Sep 2009 23:26:25 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 29B633A68B2; Mon, 7 Sep 2009 23:26:25 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n886QoL8010444; Tue, 8 Sep 2009 02:26:50 -0400 (EDT) Received: from APC ([202.120.39.240]) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n886Qhhx007043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Sep 2009 02:26:46 -0400 (EDT) Message-ID: From: "Weiqiang Sun" To: Date: Tue, 8 Sep 2009 14:26:42 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Cc: Henk Uijterwaal , Rschrage , IPPM WG IETF Subject: [CCAMP] Fw: New Version Notification for draft-ietf-ccamp-lsp-dppm-08 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, 08 Sep 2009 06:26:26 -0000 All, A new version of the DPPM draft has been uploaded. In this revision there is one technical change in 14.3. This change is made based on the discussion between Reinhard Schrage and us. In the original text, we used the percentile definition in RFC 2681. Reinhard suggested the current definition, which is detailed in RFC 2330. We believe that the current definition is more clear and easy to understand. The change is summarized below. We would again hand this draft back to Lou and Deborah for further processing. The authors believe that a second WGLC might not be necessary, since the two definitions yield similar results on large measurements. Original text: --------------------- 14.3. The percentile of Metric The percentile of Metric is defined as: given a metric and a percent X between 0% and 100%, the Xth percentile of all the dT values in the sample." In addition, the percentile is undefined if the sample is empty. Example: suppose we take a sample and the results are: Stream1 = < , , , , > Then the 50th percentile would be 110 msec, since 90 msec and 100 msec are smaller, and 110 and 500 msec are larger (undefined values are not counted in). --------------------- New text: --------------------- 14.3. The percentile of Metric The "empirical distribution function" (EDF) of a set of scalar measurements is a function F(x) which for any x gives the fractional proportion of the total measurements that were <= x. Given a percentage X, the X-th percentile of Metric means the smallest value of x for which F(x) >= X. Undefined values MUST NOT be counted in. See RFC2330 for further details. --------------------- Thanks and best regards, Weiqiang -------------------------------------------------- From: "IETF I-D Submission Tool" Sent: Tuesday, September 08, 2009 2:03 PM To: Cc: ; ; ; ; ; ; ; Subject: New Version Notification for draft-ietf-ccamp-lsp-dppm-08 > > A new version of I-D, draft-ietf-ccamp-lsp-dppm-08.txt has been > successfuly submitted by Weiqiang Sun and posted to the IETF repository. > > Filename: draft-ietf-ccamp-lsp-dppm > Revision: 08 > Title: Label Switched Path (LSP) Dynamic Provisioning Performance Metrics > in Generalized MPLS Networks > Creation_date: 2009-09-08 > WG ID: ccamp > Number_of_pages: 49 > > Abstract: > Generalized Multi-Protocol Label Switching (GMPLS) is one of the most > promising candidate technologies for future data transmission > network. GMPLS has been developed to control and operate different > kinds of network elements, such as conventional routers, switches, > Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop > Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- > connects (OXCs), etc. Dynamic provisioning ability of these > physically diverse devices differs from each other drastically. At > the same time, the need for dynamically provisioned connections is > increasing because optical networks are being deployed in metro > areas. As different applications have varied requirements in the > provisioning performance of optical networks, it is imperative to > define standardized metrics and procedures such that the performance > of networks and application needs can be mapped to each other. > > This document provides a series of performance metrics to evaluate > the dynamic LSP provisioning performance in GMPLS networks, > specifically the dynamic LSP setup/release performance. These > metrics can depict the features of GMPLS networks in LSP dynamic > provisioning. > > > > The IETF Secretariat. > > > From root@core3.amsl.com Tue Sep 8 11:30:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D9D6628C12E; Tue, 8 Sep 2009 11:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090908183001.D9D6628C12E@core3.amsl.com> Date: Tue, 8 Sep 2009 11:30:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-wson-framework-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: Tue, 08 Sep 2009 18:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-rwa-wson-framework-03.txt Pages : 45 Date : 2009-09-08 This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation architectures that could be realized via various combinations of extended GMPLS and PCE protocols. This memo focuses on topological elements and path selection constraints that are common across different WSON environments as such it does not address optical impairments in any depth nor does it address potential incompatibilities between some types of optical signals and some types of network elements and links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rwa-wson-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-08112537.I-D@ietf.org> --NextPart-- From lberger@labn.net Tue Sep 8 13:50:29 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9BD3A6A0A for ; Tue, 8 Sep 2009 13:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.243, 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 uCZmIbACwu7l for ; Tue, 8 Sep 2009 13:50:28 -0700 (PDT) Received: from outbound-mail-121.bluehost.com (outbound-mail-121.bluehost.com [67.222.38.21]) by core3.amsl.com (Postfix) with SMTP id 5F23F3A6A02 for ; Tue, 8 Sep 2009 13:50:28 -0700 (PDT) Received: (qmail 17847 invoked by uid 0); 8 Sep 2009 20:50:59 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy4.bluehost.com with SMTP; 8 Sep 2009 20:50:59 -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=KNXkOuOqFwo6trmahY8pC1FNQOhFH3toT+Va+14EN5tVOXZVSVw96EDlkS2Z3bnCP2cTGEOtYpXy7XK6DWkm3rZY7TRBVBmMfuh8ih0FO9dd32QX8NU41Ci7XW+NNdCE; 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 1Ml7eV-0004PC-92; Tue, 08 Sep 2009 14:50:59 -0600 Message-ID: <4AA6C3BE.3010805@labn.net> Date: Tue, 08 Sep 2009 16:51:10 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Weiqiang Sun References: In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org, Henk Uijterwaal , Rschrage , IPPM WG IETF Subject: Re: [CCAMP] Fw: New Version Notification for draft-ietf-ccamp-lsp-dppm-08 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, 08 Sep 2009 20:50:29 -0000 Weiqiang, Thank you for addressing the detailed comments. Given the number of differences from the previously last called version (05), I think it best to hold a second last call. I'll send the announcement in a separate message to just the ccamp WG. I think it would be helpful if you followed up the announcement with a summary of the changes from the previously last called rev. For convenience, here's the url to see the diff: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-ccamp-lsp-dppm-05.txt&url2=draft-ietf-ccamp-lsp-dppm-08.txt Lou On 9/8/2009 2:26 AM, Weiqiang Sun wrote: > All, > > A new version of the DPPM draft has been uploaded. > > In this revision there is one technical change in 14.3. This change is > made based on the discussion between Reinhard Schrage and us. In the > original text, we used the percentile definition in RFC 2681. Reinhard > suggested the current definition, which is detailed in RFC 2330. We > believe that the current definition is more clear and easy to > understand. The change is summarized below. > > We would again hand this draft back to Lou and Deborah for further > processing. The authors believe that a second WGLC might not be > necessary, since the two definitions yield similar results on large > measurements. > > Original text: > --------------------- > 14.3. The percentile of Metric > > The percentile of Metric is defined as: given a metric and a percent > X between 0% and 100%, the Xth percentile of all the dT values in the > sample." In addition, the percentile is undefined if the sample is > empty. > > Example: suppose we take a sample and the results are: Stream1 = < > , , , , 500 msec> > > > Then the 50th percentile would be 110 msec, since 90 msec and 100 > msec are smaller, and 110 and 500 msec are larger (undefined values > are not counted in). > > --------------------- > > New text: > --------------------- > 14.3. The percentile of Metric > > The "empirical distribution function" (EDF) of a set of scalar > measurements is a function F(x) which for any x gives the fractional > proportion of the total measurements that were <= x. > > Given a percentage X, the X-th percentile of Metric means the > smallest value of x for which F(x) >= X. Undefined values > MUST NOT be counted in. > > See RFC2330 for further details. > --------------------- > > Thanks and best regards, > Weiqiang > > -------------------------------------------------- > From: "IETF I-D Submission Tool" > Sent: Tuesday, September 08, 2009 2:03 PM > To: > Cc: ; ; > ; ; ; > ; ; > Subject: New Version Notification for draft-ietf-ccamp-lsp-dppm-08 > >> >> A new version of I-D, draft-ietf-ccamp-lsp-dppm-08.txt has been >> successfuly submitted by Weiqiang Sun and posted to the IETF repository. >> >> Filename: draft-ietf-ccamp-lsp-dppm >> Revision: 08 >> Title: Label Switched Path (LSP) Dynamic Provisioning Performance >> Metrics in Generalized MPLS Networks >> Creation_date: 2009-09-08 >> WG ID: ccamp >> Number_of_pages: 49 >> >> Abstract: >> Generalized Multi-Protocol Label Switching (GMPLS) is one of the most >> promising candidate technologies for future data transmission >> network. GMPLS has been developed to control and operate different >> kinds of network elements, such as conventional routers, switches, >> Dense Wavelength Division Multiplexing (DWDM) systems, Add- Drop >> Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- >> connects (OXCs), etc. Dynamic provisioning ability of these >> physically diverse devices differs from each other drastically. At >> the same time, the need for dynamically provisioned connections is >> increasing because optical networks are being deployed in metro >> areas. As different applications have varied requirements in the >> provisioning performance of optical networks, it is imperative to >> define standardized metrics and procedures such that the performance >> of networks and application needs can be mapped to each other. >> >> This document provides a series of performance metrics to evaluate >> the dynamic LSP provisioning performance in GMPLS networks, >> specifically the dynamic LSP setup/release performance. These >> metrics can depict the features of GMPLS networks in LSP dynamic >> provisioning. >> >> >> >> The IETF Secretariat. >> >> >> > > > From lberger@labn.net Tue Sep 8 13:54:03 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6DB3A68DD for ; Tue, 8 Sep 2009 13:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_20=-0.74, 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 1chkBuslMXuF for ; Tue, 8 Sep 2009 13:54:02 -0700 (PDT) Received: from outbound-mail-02.bluehost.com (outbound-mail-02.bluehost.com [69.89.21.12]) by core3.amsl.com (Postfix) with SMTP id C6EC03A691A for ; Tue, 8 Sep 2009 13:54:02 -0700 (PDT) Received: (qmail 19714 invoked by uid 0); 8 Sep 2009 20:54:33 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy1.bluehost.com with SMTP; 8 Sep 2009 20:54:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=ulgj3sXHZ0vX9NUrarqZFO98OOAomatM+D6Xk1UIPpvJ8EkxRFOfEE/SAgBWdVUVlWtq03IGnyeSCQP5VuIMf2LxA8X50xa7HvhGaNBblN/kolyIXcPE2dvoPo4qJuK2; 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 1Ml7hx-0005gk-KI for ccamp@ietf.org; Tue, 08 Sep 2009 14:54:33 -0600 Message-ID: <4AA6C495.4080306@labn.net> Date: Tue, 08 Sep 2009 16:54:45 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: ccamp@ietf.org X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm 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, 08 Sep 2009 20:54:03 -0000 This email begins a two week working group last call on draft-ietf-ccamp-lsp-dppm-08.txt http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-08 Please send your comments to the list or the authors before the last call closes on September 22, 2009. As discussed on the list, we are holding an additional last call on this draft due to the changes made as a result of the previous Last Call. For convenience, here's the url to see the diff: http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-ccamp-lsp-dppm-05.txt&url2=draft-ietf-ccamp-lsp-dppm-08.txt From sunwq@MIT.EDU Tue Sep 8 19:46:35 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079B23A67ED for ; Tue, 8 Sep 2009 19:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-aFwR7ms8qy for ; Tue, 8 Sep 2009 19:46:34 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id D0BA13A6808 for ; Tue, 8 Sep 2009 19:46:33 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n892l0Mf026035; Tue, 8 Sep 2009 22:47:01 -0400 (EDT) Received: from APC ([202.120.39.240]) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n892kuIm029858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 8 Sep 2009 22:46:59 -0400 (EDT) Message-ID: From: "Weiqiang Sun" To: "Lou Berger" , References: <4AA6C495.4080306@labn.net> In-Reply-To: <4AA6C495.4080306@labn.net> Date: Wed, 9 Sep 2009 10:46:53 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm 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, 09 Sep 2009 02:46:35 -0000 Thanks, Lou. I did not realize we have gone so far since the 1st LC. :) A summary of the changes - A number of editorial changes, including 1. As per Tom's comments, we have droped the following two sentenses. - They can also be used in operational networks for carriers to monitor the control plane performance in realtime. - On the other hand, it can also be used in operational environments for carriers to monitor the control plane operation in real-time. For example, a new object can be added to GMPLS TE STD MIB [RFC4802] so that the current and past control plane performance can be monitored through network management systems. The extension of TE-MIB to support the defined metrics is outside the scope of this document. 2. The change made throughout the document: Unidirectional/Bidirectional -> Uni-directional/Bi-directional 3. And a lot others... Three technical changes, including 1. As per Lou's LC comments on formal conformance language, we have added formal language at the points where we think applicable. These include: a. Section 2 is recovered. b. In Section 3: An implementation MAY choose whether to implement metrics in the two documents together. c. In Section 3: However, it is RECOMMENDED that both measurements are performed to complement each other. d. In section 4.6-8.6: Simple upper bounds MAY be used. e. In section 4.6-8.6: In practice, the upper bound should be chosen carefully and the value MUST be reported. f. In section 4.6: If ingress node sends out the PATH message to set up an LSP, but never receive receives the corresponding RESV message, the uni-directional LSP setup delay MUST be set to undefined. g. In section 4.6: If the ingress node sends out the PATH message to set up an LSP but receive receives a PathErr message, the uni-directional LSP setup delay MUST be set to undefined. h. In section 6.6: If the ingress node sends out the PATH message to set up the LSP, but never receives the corresponding RESV message, single bi-directional LSP setup delay MUST be set to undefined. i. In section 6.6: If the ingress node sends out the PATH message to set up the LSP, but receives PathErr message, single bi-directional LSP setup delay MUST be set to undefined. j. In section 7.6: If the ingress node sends out the PATH messages to set up the LSPs, but never receives all the corresponding RESV messages, the multiple bi-directional LSPs setup delay MUST be set to undefined. k. In section 7.6: If the ingress node sends out the PATH messages to set up the LSPs, but receives one or more responding PathErr messages, the multiple bi-directional LSPs setup delay is also deemed to MUST be set to undefined. l. In section 8.6: ..., but the egress node never receives the corresponding RESV PathTear message, LSP graceful release delay MUST be set to undefined. m. In section 8.6: ..., but never receives the corresponding PathTear message, LSP graceful release delay MUST be set to undefined; n. In section 9.5-11.5: The selection of Th SHOULD take into account that the network has sufficient resource to perform subsequent tests. o. In section 9.5-11.5: The value of Th MAY be constant during one sampling process for simplicity considerations. p. In section 14.1: In computing this, undefined values SHOULD be treated as infinitely large. q. In section 14.1: In addition, the metric minimum SHOULD be set to undefined if the sample is empty. r. In section 14.3: Undefined values MUST NOT be counted in. 2. As per Lou's LC comments, We removed section "13. Discussion for unsuccessful setup/release cases" in the original text and added a sub-section in section 14: "14.4. Failure statistics of Metric" And also, in each metrics definition sections, we added a referencing paragraph: The undefined value of this metric indicates an event of Single Uni- directional LSP Setup Failure, and would be used to report a count or an percentage of Single Uni-directional LSP Setup failures. See section Section 14.4 for definitions of LSP setup/release failures. 3. As per Reinhard's comments, we redefined percentile into the current look: 14.3. The percentile of Metric The "empirical distribution function" (EDF) of a set of scalar measurements is a function F(x) which for any x gives the fractional proportion of the total measurements that were <= x. Given a percentage X, the X-th percentile of Metric means the smallest value of x for which F(x) >= X. Undefined values MUST NOT be counted in. See RFC2330 for further details. Thank you, Weiqiang -------------------------------------------------- From: "Lou Berger" Sent: Wednesday, September 09, 2009 4:54 AM To: Subject: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm > This email begins a two week working group last call on > draft-ietf-ccamp-lsp-dppm-08.txt > > http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-08 > > Please send your comments to the list or the authors before the last > call closes on September 22, 2009. > > As discussed on the list, we are holding an additional last call on > this draft due to the changes made as a result of the previous Last > Call. For convenience, here's the url to see the diff: > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-ccamp-lsp-dppm-05.txt&url2=draft-ietf-ccamp-lsp-dppm-08.txt > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From root@core3.amsl.com Wed Sep 9 08:45:01 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D9E6E28C3F6; Wed, 9 Sep 2009 08:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090909154501.D9E6E28C3F6@core3.amsl.com> Date: Wed, 9 Sep 2009 08:45:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-info-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-rwa-info-04.txt Pages : 18 Date : 2009-09-09 This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs, particularly in cases where there are no or a limited number of wavelength converters available. This model does not include optical impairments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rwa-info-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-09084054.I-D@ietf.org> --NextPart-- From ylee@huawei.com Wed Sep 9 08:56:34 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26E7F3A6A47 for ; Wed, 9 Sep 2009 08:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKLMTDkgKRms for ; Wed, 9 Sep 2009 08:56:33 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 4CE4628C44C for ; Wed, 9 Sep 2009 08:56:33 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KPP005IZOB5HU@usaga04-in.huawei.com> for ccamp@ietf.org; Wed, 09 Sep 2009 10:57:06 -0500 (CDT) Received: from L73682 ([10.124.12.76]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KPP00491OAY88@usaga04-in.huawei.com> for ccamp@ietf.org; Wed, 09 Sep 2009 10:57:05 -0500 (CDT) Date: Wed, 09 Sep 2009 10:56:58 -0500 From: Young Lee To: "'BRUNGARD, DEBORAH A, ATTLABS'" , lberger@labn.net Message-id: <002d01ca3166$2ace2a60$4c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_/eU5NR7x4HUA6dBunIi+dw)" Thread-index: AcoxZilJ4lREX0aPSD6Uod5/L9624w== Cc: ccamp@ietf.org, 'Adrian Farrel' Subject: [CCAMP] WSON RWA Framework and Information Drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:56:34 -0000 This is a multi-part message in MIME format. --Boundary_(ID_/eU5NR7x4HUA6dBunIi+dw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Deborah and Lou, We have just uploaded (i) WSON RWA Framework draft (03 version) and (ii) RWA Information Model for WSON (04 version). http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-03.t xt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-04.txt The authors believe that both of these drafts are stable and ready to move to WG Last Call. We'd appreciate your review and feedback. Thanks. Best Regards, Young & Greg --Boundary_(ID_/eU5NR7x4HUA6dBunIi+dw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Deborah and Lou,

 

We have just uploaded (i) WSON RWA Framework draft (03 version) and (ii) RWA Information Model for WSON (04 version).

 

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-03.txt

 

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-04.txt

 

The authors believe that both of these drafts are stable and ready to move to WG Last Call. We'd appreciate your review and feedback. Thanks.

 

Best Regards,

Young & Greg

 

--Boundary_(ID_/eU5NR7x4HUA6dBunIi+dw)-- From vishwas.ietf@gmail.com Thu Sep 10 10:52:20 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0CAF3A6995 for ; Thu, 10 Sep 2009 10:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 bmHQLOfqFgXh for ; Thu, 10 Sep 2009 10:52:19 -0700 (PDT) Received: from mail-yw0-f195.google.com (mail-yw0-f195.google.com [209.85.211.195]) by core3.amsl.com (Postfix) with ESMTP id 035763A6825 for ; Thu, 10 Sep 2009 10:52:18 -0700 (PDT) Received: by ywh33 with SMTP id 33so484027ywh.18 for ; Thu, 10 Sep 2009 10:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=7400HILWrR3aPF7LiX3QOBFrCxubA2vZlDuoL4EeMkk=; b=GE92tiIs77Ktg9c7vZdnbHPmSlj2hD3a48Y0ofdXk4ez854qQH3yN9tUUxTgeO+dBE +ypITzE0tW4dR61y2//O75xzRpRwZhJDeZ43xrm6YPnGTGY3RwuzLgjkFWxY7q3mC4p/ NMd55R64RwmLPWJaEtYzolZQgHhg7/DZs2jbw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=A88djhWS3GSjix0PL9ZWMEEJRSBDW/n7frEDtHPNNMJAUj15TuGAyW73so0TTj3msT wyR/sCi5UKGyWpXfxvw63GC0e0kce0CZrebNXJfmrlGXW+8DKnJoFDQEusRG85ufhe8u SJEgVVkRBCISpf2CIkzk/tKwLWhLliU1MBu20= MIME-Version: 1.0 Received: by 10.150.40.2 with SMTP id n2mr3203042ybn.122.1252605168966; Thu, 10 Sep 2009 10:52:48 -0700 (PDT) In-Reply-To: <77ead0ec0909021110p3cc7c215x7f388241724d42bf@mail.gmail.com> References: <77ead0ec0909021110p3cc7c215x7f388241724d42bf@mail.gmail.com> Date: Thu, 10 Sep 2009 10:52:48 -0700 Message-ID: <77ead0ec0909101052g2a4623afk6bc59d363f6ac147@mail.gmail.com> From: Vishwas Manral To: ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [CCAMP] LMP MIB 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, 10 Sep 2009 17:52:20 -0000 Reforwarding as I did not hear from the authors. Thanks, Vishwas On Wed, Sep 2, 2009 at 11:10 AM, Vishwas Manral wr= ote: > Hi, > > The LMP spec allows the value of 0 for the Hello Interval. The Textual > convention in the LMP MIB used by the lmpCcHelloInterval object > LmpInterval is defined as > > LmpInterval ::=3D TEXTUAL-CONVENTION > =A0 DISPLAY-HINT "d" > =A0 STATUS =A0 =A0 =A0 =A0current > =A0 DESCRIPTION > =A0 =A0 =A0 "The interval delay, in milliseconds." > =A0 SYNTAX =A0 =A0 =A0 =A0Unsigned32 (1..65535) > > where a value of 0 cannot be set. I think the textual convention > should be changed to > > LmpInterval ::=3D TEXTUAL-CONVENTION > =A0 DISPLAY-HINT "d" > =A0 STATUS =A0 =A0 =A0 =A0current > =A0 DESCRIPTION > =A0 =A0 =A0 "The interval delay, in milliseconds." > =A0 SYNTAX =A0 =A0 =A0 =A0Unsigned32 (0..65535) > > Thanks, > Vishwas > From vishwas.ietf@gmail.com Thu Sep 10 10:53:52 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F673A6995 for ; Thu, 10 Sep 2009 10:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 LLlhXAPbz1Eu for ; Thu, 10 Sep 2009 10:53:51 -0700 (PDT) Received: from mail-yx0-f200.google.com (mail-yx0-f200.google.com [209.85.210.200]) by core3.amsl.com (Postfix) with ESMTP id A78923A68D3 for ; Thu, 10 Sep 2009 10:53:27 -0700 (PDT) Received: by yxe38 with SMTP id 38so445528yxe.6 for ; Thu, 10 Sep 2009 10:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=zJkaTp7k/d/EtaqHT+FA1809VsEWuRSFS9GyN0teoKQ=; b=sf++m2tsxEo35WcVRkmA4HZaHt4lnomsFsg+2Q/HfpNVgHjFDyKX22ANhvVCYJmgUL ZatxmTMRigPSqJ9CsTLlttVqUGR1xgLsxLR6epjNK18tmpfu0vuh0ODSDLH8+YssEFJw 3XLXOszGuJpNiOOk62DRV+dULFwlhYpCyk1g4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=v2+Agk6vRvydblsdjmPknnOlWAT8G5JXWjvhtH4/sO6shymUATSqEcgy/qhnPFaOXe ZfBdthAzFUJk65LEPifYXbGVPVg3SUyyE8JLcOQHsCqxq/dlqYdm9ah5YBDFTKEIYDpF veySTtdJdqOLX/bxJ2OEiwmpkCaj6mPUhkCIA= MIME-Version: 1.0 Received: by 10.150.45.20 with SMTP id s20mr3114066ybs.211.1252605243062; Thu, 10 Sep 2009 10:54:03 -0700 (PDT) In-Reply-To: <77ead0ec0909021055r61d62abbg3c8bb5c203ec3aa5@mail.gmail.com> References: <77ead0ec0909021055r61d62abbg3c8bb5c203ec3aa5@mail.gmail.com> Date: Thu, 10 Sep 2009 10:54:02 -0700 Message-ID: <77ead0ec0909101054o77058a8do62dc67491bc9423f@mail.gmail.com> From: Vishwas Manral To: ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [CCAMP] Fwd: LMP MIB 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, 10 Sep 2009 17:53:53 -0000 Reforwarding as did not hear from the authors. Thanks, Vishwas ---------- Forwarded message ---------- From: Vishwas Manral Date: Wed, Sep 2, 2009 at 10:55 AM Subject: LMP MIB To: ccamp@ietf.org Hi, I find the LMP MIB does not seem to take care of the case of "LMP adjacency" at all. It seems it has been designed to work in the case where there is only a single control channel between a pair of nodes. I do not find a table for that in the MIB. =A0 An "LMP adjacency" is formed between two nodes when at least one bi- =A0 directional control channel is established between them. =A0Multiple =A0 control channels may be active simultaneously for each adjacency; =A0 control channel parameters, however, MUST be individually negotiated =A0 for each control channel. I see a lot of counters in the counter table based on the Control Channel basis, actually are adjacency level counters, which are not. Even though we are allowing fast keepalives, we are having counter32 and not counter64, even for Hellos. Thanks, Vishwas From julien.meuric@orange-ftgroup.com Fri Sep 11 02:41:29 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2513A6AC9; Fri, 11 Sep 2009 02:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6zadnUCaGPi; Fri, 11 Sep 2009 02:41:27 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id C1EDF3A6A78; Fri, 11 Sep 2009 02:41:26 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Sep 2009 11:41:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Sep 2009 11:41:18 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Proposed Liaison to ITU SG15 Q6, Q12, and Q14 on WSON Impairments Thread-Index: AcotajJwLzHgQ3siTeujCLjYQVrJwQFUYooA References: From: To: , X-OriginalArrivalTime: 11 Sep 2009 09:41:20.0331 (UTC) FILETIME=[047621B0:01CA32C4] Cc: pce@ietf.org Subject: Re: [CCAMP] Proposed Liaison to ITU SG15 Q6, Q12, and Q14 on WSON Impairments 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, 11 Sep 2009 09:41:29 -0000 Hi Deborah, hi Lou. I would like to see some clarification to the statement "the parameter = information which is needed to be distributed by either a control plane = or Path Computation Element". May I suggest to rephrase by something = like: "the parameter information which is needed to be distributed by a = control plane, so as to be used by either node internal path computation = or a Path Computation Element"? I CC the PCE list in case some interested people be not subscribed to = CCAMP. Thanks, Julien -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of BRUNGARD, DEBORAH A, ATTLABS CCAMP, As we agreed, we need to send a liaison to ITU's SG15 Q6, Q12, and Q14, = informing them of our CCAMP document, "A Framework for the Control of = Wavelength Switched Optical Networks (WSON) with Impairments".=20 This is in response to the ITU liaison: https://datatracker.ietf.org/liaison/479/ Note, the link below in the liaison points to the ITU link. The link for = CCAMP is: http://www.ccamp.labn.net/old_ccamp/www.olddog.co.uk/download/WD6-38.doc Let us know if any comments on this proposal. Deborah and Lou -----------------Proposed Liaison-------------------- From: IETF CCAMP WG To: ITU-T Study Group 15 Question 6, Question 12, and Question 14 Peter Stassar Pete Anslow Malcolm Betts Hing-Kam Lam Ross Callon Adrian Farrel Cc: Patrik F=E4ltstr=F6m=20 Francesco Montalti Stephen Trowbridge Title: WSON Impairment Work in CCAMP Purpose: For Information =20 The CCAMP Working Group of IETF thanks Question 12 for their liaison = from the September 2008 meeting informing of their initiation of work to = be done in cooperation with Question 6 on developing a network model for = WSON which will include optical impairments. We would like to inform you = of our progress in this area as documented in the CCAMP document "A = Framework for the Control of Wavelength Switched Optical Networks (WSON) = with Impairments": http://www.ietf.org/id/draft-ietf-ccamp-wson-impairments-00.txt This document provides a framework for GMPLS protocols and mechanisms to = support impairment aware routing and wavelength assignment. The = deployment scenarios are based on the categories discussed at Question = 6's Sunnyvale meeting: = http://ifa.itu.int/t/2009/sg15/exchange/wp2/q6/Meetings/2009-03-Sunnyvale= /Contributions/WD6-38.doc We would appreciate your consideration of this document in your work and = would you please inform us of the scope of your work and the timelines. = For CCAMP's impairment work, CCAMP is focused on scenarios where = approximated impairment estimation using ITU-T defined parameters and = approximation techniques [G.680] may be used. The objective of CCAMP = work is to distribute the information which is needed to allow path = computation and signaling of new paths. We would appreciate your input = on the parameter information which is needed to be distributed by either = a control plane or Path Computation Element (PCE) and its properties so = as to understand the control plane distribution requirements. In = addition, we would appreciate your perspective on control plane modeling = and implications with regard to ITU-T's G.872 OTN aspects e.g. OTN = multi-layers (OTS, OMS, OCh), regenerators, and o/e/o (OCh/OTU/ODU). Best Regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From dbrungard@att.com Fri Sep 11 09:35:58 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E4053A6A31; Fri, 11 Sep 2009 09:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.458 X-Spam-Level: X-Spam-Status: No, score=-106.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 KL3pJSAQnkal; Fri, 11 Sep 2009 09:35:57 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id C6F083A689B; Fri, 11 Sep 2009 09:35:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-4.tower-121.messagelabs.com!1252686992!22665903!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 28292 invoked from network); 11 Sep 2009 16:36:32 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Sep 2009 16:36:32 -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 n8BGaWMr019871; Fri, 11 Sep 2009 12:36:32 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n8BGaRTC019843; Fri, 11 Sep 2009 12:36:29 -0400 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: Fri, 11 Sep 2009 12:35:52 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] Proposed Liaison to ITU SG15 Q6, Q12, and Q14 on WSON Impairments Thread-Index: AcotajJwLzHgQ3siTeujCLjYQVrJwQFUYooAABB004A= References: From: "BRUNGARD, DEBORAH A, ATTLABS" To: , Cc: pce@ietf.org Subject: Re: [CCAMP] Proposed Liaison to ITU SG15 Q6, Q12, and Q14 on WSON Impairments 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, 11 Sep 2009 16:35:58 -0000 Hi Julien, Great - thanks for the clarification. I'll update. Deborah -----Original Message----- From: julien.meuric@orange-ftgroup.com = [mailto:julien.meuric@orange-ftgroup.com]=20 Sent: Friday, September 11, 2009 5:41 AM To: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ietf.org Cc: pce@ietf.org Subject: RE: [CCAMP] Proposed Liaison to ITU SG15 Q6, Q12,and Q14 on = WSON Impairments Hi Deborah, hi Lou. I would like to see some clarification to the statement "the parameter = information which is needed to be distributed by either a control plane = or Path Computation Element". May I suggest to rephrase by something = like: "the parameter information which is needed to be distributed by a = control plane, so as to be used by either node internal path computation = or a Path Computation Element"? I CC the PCE list in case some interested people be not subscribed to = CCAMP. Thanks, Julien -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of BRUNGARD, DEBORAH A, ATTLABS CCAMP, As we agreed, we need to send a liaison to ITU's SG15 Q6, Q12, and Q14, = informing them of our CCAMP document, "A Framework for the Control of = Wavelength Switched Optical Networks (WSON) with Impairments".=20 This is in response to the ITU liaison: https://datatracker.ietf.org/liaison/479/ Note, the link below in the liaison points to the ITU link. The link for = CCAMP is: http://www.ccamp.labn.net/old_ccamp/www.olddog.co.uk/download/WD6-38.doc Let us know if any comments on this proposal. Deborah and Lou -----------------Proposed Liaison-------------------- From: IETF CCAMP WG To: ITU-T Study Group 15 Question 6, Question 12, and Question 14 Peter Stassar Pete Anslow Malcolm Betts Hing-Kam Lam Ross Callon Adrian Farrel Cc: Patrik F=E4ltstr=F6m=20 Francesco Montalti Stephen Trowbridge Title: WSON Impairment Work in CCAMP Purpose: For Information =20 The CCAMP Working Group of IETF thanks Question 12 for their liaison = from the September 2008 meeting informing of their initiation of work to = be done in cooperation with Question 6 on developing a network model for = WSON which will include optical impairments. We would like to inform you = of our progress in this area as documented in the CCAMP document "A = Framework for the Control of Wavelength Switched Optical Networks (WSON) = with Impairments": http://www.ietf.org/id/draft-ietf-ccamp-wson-impairments-00.txt This document provides a framework for GMPLS protocols and mechanisms to = support impairment aware routing and wavelength assignment. The = deployment scenarios are based on the categories discussed at Question = 6's Sunnyvale meeting: = http://ifa.itu.int/t/2009/sg15/exchange/wp2/q6/Meetings/2009-03-Sunnyvale= /Contributions/WD6-38.doc We would appreciate your consideration of this document in your work and = would you please inform us of the scope of your work and the timelines. = For CCAMP's impairment work, CCAMP is focused on scenarios where = approximated impairment estimation using ITU-T defined parameters and = approximation techniques [G.680] may be used. The objective of CCAMP = work is to distribute the information which is needed to allow path = computation and signaling of new paths. We would appreciate your input = on the parameter information which is needed to be distributed by either = a control plane or Path Computation Element (PCE) and its properties so = as to understand the control plane distribution requirements. In = addition, we would appreciate your perspective on control plane modeling = and implications with regard to ITU-T's G.872 OTN aspects e.g. OTN = multi-layers (OTS, OMS, OCh), regenerators, and o/e/o (OCh/OTU/ODU). Best Regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From dbrungard@att.com Fri Sep 11 13:27:34 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD5D3A6A9B for ; Fri, 11 Sep 2009 13:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.087 X-Spam-Level: X-Spam-Status: No, score=-106.087 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799, 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 zXZe9VVrWd4K for ; Fri, 11 Sep 2009 13:27:33 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id D04713A6864 for ; Fri, 11 Sep 2009 13:27:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-9.tower-146.messagelabs.com!1252700889!18654845!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 31800 invoked from network); 11 Sep 2009 20:28:09 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Sep 2009 20:28:09 -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 n8BKSA89028915 for ; Fri, 11 Sep 2009 16:28:10 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n8BKS6M2028903 for ; Fri, 11 Sep 2009 16:28:07 -0400 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: Fri, 11 Sep 2009 16:27:46 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed Liaison to ITU on OTNT Work Plan Thread-Index: AcozFcv1TPjoO4FxQemjz6EwCWBUCAAAZ1pA From: "BRUNGARD, DEBORAH A, ATTLABS" To: Subject: [CCAMP] Proposed Liaison to ITU on OTNT Work Plan 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, 11 Sep 2009 20:27:34 -0000 CCAMP, We previously sent comments to the ITU-T on their work plan for Optical = Transport Networks and Technologies. They have sent us an update and = asked for comments: https://datatracker.ietf.org/liaison/490/ We've updated the ccamp tables for our recent RFCs and drafts (below = I've included as text version and the changes are not highlighted, for = the liaison will include as an attachment with the changes highlighted). = Let us know if any comments on this proposal. Deborah and Lou -----------------Proposed Liaison-------------------- From: IETF CCAMP WG To: ITU-T Study Group 15 Question 3 George Young Ross Callon Adrian Farrel Cc: Patrik F=E4ltstr=F6m Stephen Trowbridge Title: Response to your ITU-T SG15 OTNT Standardization Work Plan Purpose: For comment =20 The CCAMP Working Group of IETF thanks Question 3 for sharing their Work = Plan in a liaison from the December 2008 meeting. We have updated Table = 7-1-2 for the CCAMP related work.=20 Best Regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs TABLE 7-1-2/OTNT: OTNT Related Standards and Industry Agreements (IETF = RFCs and Internet Drafts) Organisation (Subgroup responsible) Number Title Public. Date=09 IETF (ccamp) RFC 3468, The Multiprotocol Label Switching (MPLS) Working = Group decision on MPLS signaling protocols 02/2003=09 IETF (ccamp) RFC 3609 Tracing Requirements for Generic Tunnels 09/2003=09 IETF (ccamp) RFC 3945 Generalized Multi-Protocol Label Switching = Architecture 10/2004=09 IETF (ccamp) RFC 4003 GMPLS Signaling Procedure For Egress Control - = updates RFC 3473 02/2005=09 IETF (ccamp) RFC 4139 Requirements for Generalized MPLS (GMPLS) = Signaling Usage and Extensions for Automatically Switched Optical = Network (ASON) 07/2005=09 IETF (ccamp) RFC 4201 Link Bundling in MPLS Traffic Engineering (TE) = 10/2005=09 IETF (ccamp) RFC 4202 Routing Extensions in Support of Generalized = Multi-Protocol Label Switching (GMPLS) 10/2005=09 IETF (ccamp) RFC 4203 OSPF Extensions in Support of Generalized = Multi-Protocol Label Switching - updates RFC 3630 10/2005=09 IETF (ccamp) RFC 4204 Link Management Protocol (LMP) 10/2005=09 IETF (ccamp) RFC 4207 Synchronous Optical Network (SONET)/Synchronous = Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test = Messages 10/2005=09 IETF (ccamp) RFC4208 Generalize Multiprotocol Label Switching(GMPLS) = User-Network Interface (UNI): Resource ReserVation Protocol-Traffic = Engineering (RSVP-TE) Support for the Overlay Model 10/2005=09 IETF (ccamp) RFC4209 Link Management Protocol (LMP) for Dense Wavelength = Division Multiplexing (DWDM) Optical Line Systems 10/2005=09 IETF (ccamp) RFC4258 Requirements for Generalized Multi-Protocol Label = Switching (GMPLS) Routing for the Automatically Switched Optical Network = (ASON) 11/2005=09 IETF (ccamp) RFC4257 Framework for Generalized Multi-Protocol Label = Switching (GMPLS)-based Control of Synchronous Digital = Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks 12/2005=09 IETF (ccamp) RFC4328 Generalized Multi-Protocol Label Switching (GMPLS) = Signaling Extensions for G.709 Optical Transport Networks Control - = updates RFC 3471 01/2006=09 IETF (ccamp) RFC4394 A Transport Network View of the Link Management = Protocol 02/2006=09 IETF (ccamp) RFC4397 A Lexicography for the Interpretation of = Generalized Multiprotocol Label Switching (GMPLS) Terminology within The = Context of the ITU-T's Automatically Switched Optical Network (ASON) = Architecture 02/2006=09 IETF (ccamp) RFC5420 Encoding of Attributes for Multiprotocol Label = Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource = ReserVation Protocol-Traffic Engineering (RSVP-TE) 02/2009=09 IETF (ccamp) RFC4426 Generalized Multi-Protocol Label Switching (GMPLS) = Recovery Functional Specification 03/2006=09 IETF (ccamp) RFC4427 Recovery (Protection and Restoration) Terminology = for Generalized Multi-Protocol Label Switching (GMPLS) 03/2006=09 IETF (ccamp) RFC4428 Analysis of Generalized Multi-Protocol Label = Switching (GMPLS)-based Recovery Mechanisms (including Protection and = Restoration) 03/2006=09 IETF (ccamp) RFC4558 Node ID based RSVP Hello: A Clarification Statement = 06/2006=09 IETF (ccamp) RFC4606 Generalized Multi-Protocol Label Switching (GMPLS) = Extensions for Synchronous Optical Network (SONET) and Synchronous = Digital Hierarchy (SDH) Control 08/2006=09 IETF (ccamp) RFC4631 Link Management Protocol (LMP) Management = Information Base (MIB) - updates RFC4327 09/2006=09 IETF (ccamp) RFC4801 Definitions of Textual Conventions for Generalized = Multiprotocol Label Switching (GMPLS) Management 02/2007=09 IETF (ccamp) RFC4802 Generalized Multiprotocol Label Switching (GMPLS) = Traffic Engineering Management Information Base 02/2007=09 IETF (ccamp) RFC4803 Generalized Multiprotocol Label Switching (GMPLS) = Label Switching Router (LSR) Management Information Base 02/2007=09 IETF (ccamp) RFC4874 Exclude Routes - Extension to RSVP-TE 04/2007=09 IETF (ccamp) RFC4920 Crankback Signaling Extensions for MPLS and GMPLS = RSVP-TE 07/2007=09 IETF (ccamp) RFC4783 GMPLS - Communication of Alarm Information 12/2006=09 IETF (ccamp) RFC4872 RSVP-TE Extensions in support of End-to-End = Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery = 05/2007=09 IETF (ccamp) RFC4873 GMPLS Based Segment Recovery 05/2007=09 IETF (ccamp) RFC4726 A Framework for Inter-Domain MPLS Traffic = Engineering 11/2006=09 IETF (ccamp) RFC4736 Reoptimization of Multiprotocol Label Switching = (MPLS) Traffic Engineering (TE) loosely routed Label Switch Path (LSP) = 11/2006=09 IETF (ccamp) RFC5063 Extensions to GMPLS RSVP Graceful Restart 10/2007=09 IETF (ccamp) RFC5152 A Per-domain path computation method for = establishing Inter-domain Traffic Engineering (TE) Label Switched Paths = (LSPs) 2/2008=09 IETF (ccamp) RFC4652 Evaluation of existing Routing Protocols against = ASON routing requirements 10/2006=09 IETF (ccamp) draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt OSPFv2 = Routing Protocols Extensions for ASON Routing =09 IETF (ccamp) RFC4990 Use of Addresses in Generalized Multi-Protocol = Label Switching (GMPLS) Networks 09/2007=09 IETF (ccamp) RFC4972 Routing extensions for discovery of Multiprotocol = (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) mesh = membership 07/2007=09 IETF (ccamp) RFC5073 Routing extensions for discovery of Traffic = Engineering Node Capabilities 12/2007=09 IETF (ccamp) RFC5212 Requirements for GMPLS-based multi-region and = multi-layer networks (MRN/MLN)) 7/2008=09 IETF (ccamp) RFC5339 Evaluation of existing GMPLS Protocols against = Multi Layer and Multi Region Networks (MLN/MRN) 9/2008=09 IETF (ccamp) RFC5151 Inter domain Multiprotocol Label Switching (MPLS) = and Generalized MPLS (GMPLS) Traffic Engineering - RSVP-TE extensions = 2/2008=09 IETF (ccamp) RFC5150 Label Switched Path Stitching with Generalized = Multiprotocol Label Switching Traffic Engineering (GMPLS TE) 2/2008=09 IETF (ccamp) RFC4974 Generalized MPLS (GMPLS) RSVP-TE Signaling = Extensions in support of Calls 08/2007=09 IETF (ccamp) draft-ietf-ccamp-lsp-hierarchy-bis-01.txt Procedures for = Dynamically Signaled Hierarchical Label Switched Paths =09 IETF (ccamp) RFC5145 Framework for MPLS-TE to GMPLS migration 3/2008=09 IETF (ccamp) draft-ietf-ccamp-ethernet-traffic-parameters-03.txt MEF = Ethernet Traffic Parameters =09 IETF (ccamp) draft-ietf-ccamp-gmpls-ason-routing-ospf-04.txt OSPFv2 = Routing Protocols Extensions for ASON Routing =09 IETF (ccamp) RFC5495 Graceful Shutdown in GMPLS Traffic Engineering = Networks 3/2009=09 IETF (ccamp) draft-ietf-ccamp-gmpls-vcat-lcas-03.txt Operating Virtual = Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with = Generalized Multi-Protocol Label Switching (GMPLS) =09 IETF (ccamp) draft-ietf-ccamp-gmpls-ted-mib-02.txt Traffic Engineering = Database Management Information Base in support of GMPLS =09 IETF (ccamp) RFC5493 Requirements for the Conversion Between Permanent = Connections and Switched Connections in a Generalized Multiprotocol = Label Switching (GMPLS) Network 4/2009=09 IETF (ccamp) RFC5146 Interworking Requirements to Support operation of = MPLS-TE over GMPLS networks 3/2008=09 IETF (ccamp) RFC5298 Analysis of Inter-domain Label Switched Path (LSP) = Recovery 8/2008=09 IETF (ccamp) draft-ietf-ccamp-rwa-wson-framework-03.txt Framework for = GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) =09 IETF (ccamp) draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.txt = Generalized Labels for G.694 Lambda-Switching Capable Label Switching = Routers =09 IETF (ccamp) http://www.ietf.org/id/draft-ietf-ccamp-rwa-info-04.txt = Routing and Wavelength Assignment Information Model for Wavelength = Switched Optical Networks =09 IETF (ccamp) draft-ietf-ccamp-rwa-wson-encode-02.txt Routing and = Wavelength Assignment Information Encoding for Wavelength Switched = Optical Networks =09 IETF (ccamp) draft-ietf-ccamp-wson-impairments-00.txt A Framework for = the Control of Wavelength Switched Optical Networks (WSON) with = Impairments =09 From lberger@labn.net Fri Sep 11 15:07:21 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C911A3A69BA for ; Fri, 11 Sep 2009 15:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=0.237, 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 gra9atW-VXVR for ; Fri, 11 Sep 2009 15:07:20 -0700 (PDT) Received: from outbound-mail-34.bluehost.com (outbound-mail-34.bluehost.com [69.89.18.154]) by core3.amsl.com (Postfix) with SMTP id D7C9C3A68CE for ; Fri, 11 Sep 2009 15:07:20 -0700 (PDT) Received: (qmail 19146 invoked by uid 0); 11 Sep 2009 22:07:59 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy2.bluehost.com with SMTP; 11 Sep 2009 22:07:59 -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=VQoZMFYZuURKqcAlAnwSna/RSr7A//xf9DGHgLgaNpmaNScibkbKfPxE1sUYB0mIjrmLZrMDtNA9gxCZPmy00E39rhda6Agwr7Z0ScN0TI7K2oXVapKMzpho9TFU7PCt; 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 1MmEHe-0000lu-Nl; Fri, 11 Sep 2009 16:07:59 -0600 Message-ID: <4AAACA4E.3040006@labn.net> Date: Fri, 11 Sep 2009 18:08:14 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: draft-ietf-ccamp-lsp-dppm@tools.ietf.org References: <4AA6C495.4080306@labn.net> In-Reply-To: <4AA6C495.4080306@labn.net> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm 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, 11 Sep 2009 22:07:21 -0000 Authors, The following are LC comments. There are a couple of followup points from the 1st LC and then a slew of non-technical/editorial comments. - I'm happy to see additional RFC2119 directives to match your desired document track. Don't you think it would be worthwhile to add directives on what reporting is needed for the metrics actually being measured? As I read it, only bounds are reported. This really doesn't seem to make sense. Am I missing something? - I think Section 14.4 addresses much of my earlier comment on "undefined" values. I still have a couple of additional points: Don't you think it would be worthwhile to also report the Success Count as an integer? (as percentages can yield rounding errors.) As part of the rfc2119 language you're adding related to the reporting of metrics defined in section 14, I suggest that you highlight the easily missed point of "we only consider the finite values" by including "success" as part of the metric name. I'm not sure on exact phrasing as this will depend on how you write the language. Is there a reason that you included Minimum and Median in Section 14, but not maximum? General comments: - More Your choice of the word "depict" is a bit odd. I suggest changing all instances of "depict" to "characterize" (or "quantify" where appropriate). You'll probably need to slightly the rest of the sentence to align the grammar as well. - RSVP message names should match rfc2205 conventions: OLD NEW PATH Path RESV Resv RESV_CONF ResvConf - directionality should use 2205/3473 conventions: OLD NEW uni-directional unidirectional bi-directional bidirectional Specific comments (sorry, these are out of order): OLD: Dynamic provisioning ability of these physically diverse... NEW: The dynamic provisioning ability of these physically diverse... OLD: (section 4.2) single uni-directional LSP setup delay NEW: Single uni-directional LSP setup delay OLD: systems, Add- Drop Multiplexers (ADMs), photonic cross-connects (PXCs), NEW: (drop space) systems, Add-Drop... Remove duplicate word (multiple locations): "See section Section 14.4 for" missing "message" after "PathErr" in multiple places: OLD: ... response message is PathErr, the ... NEW ... response is a PathErr message, the ... OLD: ... a count or an percentage of ... NEW: ... a count or a percentage of ... OLD: but receives PathErr message, NEW but receives a PathErr message, OLD: In practice, the upper bound should be chosen carefully ... NEW In practice, the upper bound SHOULD be chosen carefully ... OLD: The arrival rate of the Poisson process Lambda_m should be NEW: The arrival rate of the Poisson process Lambda_m SHOULD be - Counted in what? "Undefined values MUST NOT be counted in." - Another subjective word choice comment: numerically How about "integer" or "integer value"? OLD: 14.3. The percentile of Metric NEW: 14.3. The Percentile of Metric OLD: implementation,configuration NEW: implementation, configuration OLD: using three way signalling NEW: (to match rest of document) using three way signaling That's it. Lou On 9/8/2009 4:54 PM, Lou Berger wrote: > This email begins a two week working group last call on > draft-ietf-ccamp-lsp-dppm-08.txt > > http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-08 > > Please send your comments to the list or the authors before the last > call closes on September 22, 2009. > > As discussed on the list, we are holding an additional last call on > this draft due to the changes made as a result of the previous Last > Call. For convenience, here's the url to see the diff: > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-ccamp-lsp-dppm-05.txt&url2=draft-ietf-ccamp-lsp-dppm-08.txt > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From root@core3.amsl.com Sun Sep 13 10:30:02 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CECAC3A68B4; Sun, 13 Sep 2009 10:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090913173001.CECAC3A68B4@core3.amsl.com> Date: Sun, 13 Sep 2009 10:30:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-mpls-graceful-shutdown-11.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Sep 2009 17: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 : Category: Informational Expires: March 12, 2010 September 13, 2009 Author(s) : Z. Ali, et al. Filename : draft-ietf-ccamp-mpls-graceful-shutdown-11.txt Pages : 10 Date : 2009-09-13 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-11.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-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-13102458.I-D@ietf.org> --NextPart-- From gregb@grotto-networking.com Mon Sep 14 10:02:32 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D55A28C1C0 for ; Mon, 14 Sep 2009 10:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.466, 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 F5H6SfobqT5o for ; Mon, 14 Sep 2009 10:02:31 -0700 (PDT) Received: from pro46.abac.com (pro46.abac.com [66.226.64.47]) by core3.amsl.com (Postfix) with ESMTP id CA4FE3A6A99 for ; Mon, 14 Sep 2009 10:02:28 -0700 (PDT) Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id n8EH2wVK021158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Sep 2009 10:03:02 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <4AAE7742.9090205@grotto-networking.com> Date: Mon, 14 Sep 2009 10:02:58 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] How to Specify Regeneration at a particular node in RSVP-TE? X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 17:02:32 -0000 Hi folks, we are continuing to investigate the generalization of the WSON work to include regenerators, OEOs and the like. We have a question to how to best indicate via RSVP-TE that a particular processing operation such as regeneration is to take place at a particular node along the path. Previous GMPLS work supports the signaling of wavelength conversion at a particular node along the path since the Explicit Route Object (ERO) supports a label sub-object and one can use a fixed mapping such as [Otani] between labels and wavelengths. If we want to specify other types of processing at a particular node along the path should we define new ERO sub-objects? Another approach seems to be that of RFC5420 concerning LSP attributes. In particular RFC5420 states: 10.2. Communicating to Key Transit LSRs Processing for key transit LSRs (such as ABRs and ASBRs) follows exactly as for egress LSR. The only difference is that the definition of the LSP attribute in the defining RFC will state that the attribute must be acted on by these transit LSRs. Now to use this, it seems that we'd need to include the IP address of the node we want to perform the processing in the TLV, which seems kind of redundant with what we already have in the ERO... Comments, questions, other alternatives? Cheers Greg B. -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From castoldi@sssup.it Mon Sep 14 10:45:16 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F38C93A6A77 for ; Mon, 14 Sep 2009 10:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.37 X-Spam-Level: * X-Spam-Status: No, score=1.37 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_44=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 8CHRWs9CJWJo for ; Mon, 14 Sep 2009 10:45:14 -0700 (PDT) Received: from sssup.it (ms01.sssup.it [193.205.80.99]) by core3.amsl.com (Postfix) with ESMTP id 5A3733A6821 for ; Mon, 14 Sep 2009 10:45:13 -0700 (PDT) Received: from [83.61.7.92] (HELO [10.0.3.2]) by sssup.it (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 53614193; Mon, 14 Sep 2009 19:30:32 +0200 Message-ID: <4AAE8144.1090707@sssup.it> Date: Mon, 14 Sep 2009 19:45:40 +0200 From: Piero Castoldi Organization: Scuola Superiore Sant'Anna User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Greg Bernstein References: <4AAE7742.9090205@grotto-networking.com> In-Reply-To: <4AAE7742.9090205@grotto-networking.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nicola Sambo , CCAMP , Alessio Giorgetti , Nicola Andriolli , Luca Valcarenghi Subject: Re: [CCAMP] How to Specify Regeneration at a particular node in RSVP-TE? X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 17:45:16 -0000 Hi Greg and colleagues, from Pisa, Italy, we just published in JLT a possible solution for "Accounting for Shared Regenerators in GMPLS-Controlled Translucent Optical Networks" and in IEEE Network an overview of the problem. The links are: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4982668&isnumber=5210716 http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4939261&isnumber=4939253 (need access to the IEEExplore repository) If the papers contain something useful for CCAMP, we are happy to serve. Best regards, Piero and coauthors Greg Bernstein ha scritto: > Hi folks, we are continuing to investigate the generalization of the > WSON work to include regenerators, OEOs and the like. > We have a question to how to best indicate via RSVP-TE that a particular > processing operation such as regeneration is to take place at > a particular node along the path. > > Previous GMPLS work supports the signaling of wavelength conversion at a > particular node along the path since the Explicit Route Object (ERO) > supports a label sub-object and one can use a fixed mapping such as > [Otani] between labels and wavelengths. > > If we want to specify other types of processing at a particular node > along the path should we define new ERO sub-objects? > Another approach seems to be that of RFC5420 concerning LSP attributes. > In particular RFC5420 states: > 10.2. Communicating to Key Transit LSRs > Processing for key transit LSRs (such as ABRs and > ASBRs) follows > exactly as for egress LSR. The only difference is > that the > definition of the LSP attribute in the defining RFC > will state that > the attribute must be acted on by these transit LSRs. > Now to use this, it seems that we'd need to include the IP address of > the node we want to perform the processing in the TLV, which seems kind > of redundant with what we already have in the ERO... > > Comments, questions, other alternatives? > > Cheers > > Greg B. > -- ======================================================= Piero Castoldi, PhD Scuola Superiore Sant'Anna, Associate Professor CNIT National Laboratory of Photonic Networks, Director Via G. Moruzzi, 1 - 56124 Pisa - Italy office: +39 050 5492152, fax: +39 050 5492250 mobile: +39 348 8705110, skype-id: piero-sssup http://www.pierocastoldi.it - http://www.ircphonet.it ======================================================= From gregb@grotto-networking.com Mon Sep 14 10:56:02 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C43D63A6A6C for ; Mon, 14 Sep 2009 10:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.399, 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 AKOi1uxi5Glx for ; Mon, 14 Sep 2009 10:56:01 -0700 (PDT) Received: from pro46.abac.com (pro46.abac.com [66.226.64.47]) by core3.amsl.com (Postfix) with ESMTP id 8B6373A687E for ; Mon, 14 Sep 2009 10:56:01 -0700 (PDT) Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id n8EHuEBc086308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Sep 2009 10:56:15 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <4AAE83BE.7050205@grotto-networking.com> Date: Mon, 14 Sep 2009 10:56:14 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Piero Castoldi References: <4AAE7742.9090205@grotto-networking.com> <4AAE8144.1090707@sssup.it> In-Reply-To: <4AAE8144.1090707@sssup.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Nicola Sambo , CCAMP , Alessio Giorgetti , Nicola Andriolli , Luca Valcarenghi Subject: Re: [CCAMP] How to Specify Regeneration at a particular node in RSVP-TE? X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 17:56:02 -0000 Hi Piero, I'll get your papers and review. Thanks for the pointer! The Pisa groups papers have been very helpful in the past. Best Regards Greg Piero Castoldi wrote: > Hi Greg and colleagues, > > from Pisa, Italy, we just published in JLT a possible solution for > "Accounting for Shared Regenerators in GMPLS-Controlled Translucent > Optical Networks" and in IEEE Network an overview of the problem. > > The links are: > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4982668&isnumber=5210716 > > http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4939261&isnumber=4939253 > > (need access to the IEEExplore repository) > > If the papers contain something useful for CCAMP, we are happy to serve. > > Best regards, > Piero and coauthors > > Greg Bernstein ha scritto: >> Hi folks, we are continuing to investigate the generalization of the >> WSON work to include regenerators, OEOs and the like. >> We have a question to how to best indicate via RSVP-TE that a >> particular processing operation such as regeneration is to take place at >> a particular node along the path. >> >> Previous GMPLS work supports the signaling of wavelength conversion >> at a particular node along the path since the Explicit Route Object >> (ERO) supports a label sub-object and one can use a fixed mapping >> such as [Otani] between labels and wavelengths. >> >> If we want to specify other types of processing at a particular node >> along the path should we define new ERO sub-objects? >> Another approach seems to be that of RFC5420 concerning LSP >> attributes. In particular RFC5420 states: >> 10.2. Communicating to Key Transit LSRs >> Processing for key transit LSRs (such as ABRs and >> ASBRs) follows >> exactly as for egress LSR. The only difference is >> that the >> definition of the LSP attribute in the defining RFC >> will state that >> the attribute must be acted on by these transit LSRs. >> Now to use this, it seems that we'd need to include the IP address of >> the node we want to perform the processing in the TLV, which seems >> kind of redundant with what we already have in the ERO... >> >> Comments, questions, other alternatives? >> >> Cheers >> >> Greg B. >> > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From wwwrun@core3.amsl.com Mon Sep 14 14:14:41 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B878B3A683D; Mon, 14 Sep 2009 14:14:41 -0700 (PDT) From: Deborah Brungard(IETF CCAMP WG) To: George.Young@att.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090914211441.B878B3A683D@core3.amsl.com> Date: Mon, 14 Sep 2009 14:14:41 -0700 (PDT) Cc: ccamp@ietf.org, sjtrowbridge@alcatel-lucent.com, paf@cisco.com, Adrian.Farrel@huawei.com, rcallon@juniper.com Subject: [CCAMP] New Liaison Statement, "Response to your ITU-T SG15 OTNT Standardization Work Plan (December 2008)" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dbrungard@att.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 21:14:41 -0000 Title: Response to your ITU-T SG15 OTNT Standardization Work Plan (December 2008) Submission Date: 2009-09-14 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=576 From: Deborah Brungard(IETF CCAMP WG) To: ITU-T SG15 Question 3(George.Young@att.com) Cc: Greg.Jones@itu.int sjtrowbridge@alcatel-lucent.com paf@cisco.com Adrian.Farrel@huawei.com rcallon@juniper.com lberger@labn.net ccamp@ietf.org Reponse Contact: dbrungard@att.com Technical Contact: dbrungard@att.com Purpose: For information Body: The CCAMP Working Group of IETF thanks Question 3 for sharing their Work Plan in a liaison from the December 2008 meeting. We have updated Table 7-1-2 for the CCAMP related work. Best regards, Lou Berger and Deborah Brungard Co-Chairs of the CCAMP WG Attachment(s): SG15 OTNT Standardization Work Plan Table 7-1-2 Update (https://datatracker.ietf.org/documents/LIAISON/file694.pdf) From sunwq@MIT.EDU Mon Sep 14 22:23:21 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A5A3A67C0 for ; Mon, 14 Sep 2009 22:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhrl3p+FoWOo for ; Mon, 14 Sep 2009 22:23:19 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id CD4993A6A75 for ; Mon, 14 Sep 2009 22:23:18 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n8F5O0hS027962; Tue, 15 Sep 2009 01:24:00 -0400 (EDT) Received: from APC ([202.120.39.240]) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n8F5NqmG020838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 15 Sep 2009 01:23:55 -0400 (EDT) Message-ID: From: "Weiqiang Sun" To: "Lou Berger" , References: <4AA6C495.4080306@labn.net> <4AAACA4E.3040006@labn.net> In-Reply-To: <4AAACA4E.3040006@labn.net> Date: Tue, 15 Sep 2009 13:23:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Cc: ccamp@ietf.org Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm 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, 15 Sep 2009 05:23:21 -0000 Hi Lou, Thank you for the comments. Please see below. Best regards, Weiqiang -- Weiqiang Sun Shanghai Jiao Tong University http://front.sjtu.edu.cn/~sunwq/ -------------------------------------------------- From: "Lou Berger" Sent: Saturday, September 12, 2009 6:08 AM To: Cc: Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm > Authors, > > The following are LC comments. There are a couple of followup points > from the 1st LC and then a slew of non-technical/editorial comments. > > - I'm happy to see additional RFC2119 directives to match your > desired document track. Don't you think it would be worthwhile > to add directives on what reporting is needed for the metrics > actually being measured? As I read it, only bounds are reported. > This really doesn't seem to make sense. Am I missing something? > Maybe we can change the text into: ``In practice, the upper bound should be chosen carefully and the value MUST be reported along with the metric itself." Do you think it is helpful? > - I think Section 14.4 addresses much of my earlier comment on > "undefined" values. I still have a couple of additional points: > > Don't you think it would be worthwhile to also report the Success > Count as an integer? (as percentages can yield rounding errors.) Please be noted that we already have the Failure Count(14.4.1). Success Count can be easily deduced from: ``the number of all values in a sample - Failure Count". Reporting the Success Count seems a bit redundant, when the Failure count is far more important and necessary. > > As part of the rfc2119 language you're adding related to the > reporting of metrics defined in section 14, I suggest that you > highlight the easily missed point of "we only consider the > finite values" by including "success" as part of the metric > name. I'm not sure on exact phrasing as this will depend on > how you write the language. Since the undefined values are properly treated in section 14 using the rfc2119 language, maybe we can just drop the sentence "In the following discussion, we only consider the finite values." How do you think? > > Is there a reason that you included Minimum and Median in > Section 14, but not maximum? Minimum and Median values are generally more stable than maximum in a large measurement and can provide valuable sights to the DUT/SUT. We do have a bunch of other statistics that are not yet included in the document. What we can offer is a suggested sub-set, rather than a whole set. The current selection is based on rfc2679 and rfc2681. > > General comments: Many thanks for the comments below. We will make the changes accordingly. > > - More Your choice of the word "depict" is a bit odd. I > suggest changing all instances of "depict" to "characterize" > (or "quantify" where appropriate). You'll probably need to > slightly the rest of the sentence to align the grammar > as well. > > - RSVP message names should match rfc2205 conventions: > OLD NEW > PATH Path > RESV Resv > RESV_CONF ResvConf > > - directionality should use 2205/3473 conventions: > OLD NEW > uni-directional unidirectional > bi-directional bidirectional > > > Specific comments (sorry, these are out of order): > > OLD: > Dynamic provisioning ability of these physically diverse... > NEW: > The dynamic provisioning ability of these physically diverse... > > OLD: (section 4.2) > single uni-directional LSP setup delay > NEW: > Single uni-directional LSP setup delay > > OLD: > systems, Add- Drop Multiplexers (ADMs), photonic cross-connects (PXCs), > NEW: (drop space) > systems, Add-Drop... > > Remove duplicate word (multiple locations): > "See section Section 14.4 for" > > missing "message" after "PathErr" in multiple places: > OLD: > ... response message is PathErr, the ... > NEW > ... response is a PathErr message, the ... > > OLD: > ... a count or an percentage of ... > NEW: > ... a count or a percentage of ... > > OLD: > but receives PathErr message, > NEW > but receives a PathErr message, > > OLD: > In practice, the upper bound should be chosen carefully ... > NEW > In practice, the upper bound SHOULD be chosen carefully ... > > OLD: > The arrival rate of the Poisson process Lambda_m should be > NEW: > The arrival rate of the Poisson process Lambda_m SHOULD be > > - Counted in what? > "Undefined values MUST NOT be counted in." > > - Another subjective word choice comment: numerically > How about "integer" or "integer value"? > > OLD: > 14.3. The percentile of Metric > NEW: > 14.3. The Percentile of Metric > > OLD: > implementation,configuration > NEW: > implementation, configuration > > OLD: > using three way signalling > NEW: (to match rest of document) > using three way signaling > > That's it. > > Lou > > On 9/8/2009 4:54 PM, Lou Berger wrote: >> This email begins a two week working group last call on >> draft-ietf-ccamp-lsp-dppm-08.txt >> >> http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-08 >> >> Please send your comments to the list or the authors before the last >> call closes on September 22, 2009. >> >> As discussed on the list, we are holding an additional last call on >> this draft due to the changes made as a result of the previous Last >> Call. For convenience, here's the url to see the diff: >> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-ccamp-lsp-dppm-05.txt&url2=draft-ietf-ccamp-lsp-dppm-08.txt >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From giomarti@cisco.com Tue Sep 15 08:25:24 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 189A53A6A53 for ; Tue, 15 Sep 2009 08:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7reiQY+iX-SQ for ; Tue, 15 Sep 2009 08:25:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AAF783A6A4F for ; Tue, 15 Sep 2009 08:25:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8AAChPr0qQ/uCKe2dsb2JhbACbSwEBFiQGqyWITAGPeAWEFw X-IronPort-AV: E=Sophos;i="4.44,390,1249257600"; d="scan'208";a="49420204" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 Sep 2009 15:26:08 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8FFQ8Eg009878 for ; Tue, 15 Sep 2009 17:26:08 +0200 Received: from [10.61.110.21] (dhcp-10-61-110-21.cisco.com [10.61.110.21]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8FFQ8Br025701 for ; Tue, 15 Sep 2009 15:26:08 GMT Message-ID: <4AAFB210.8000802@cisco.com> Date: Tue, 15 Sep 2009 17:26:08 +0200 From: Giovanni Martinelli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1329; t=1253028368; x=1253892368; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=giomarti@cisco.com; z=From:=20Giovanni=20Martinelli=20 |Subject:=20rwa=20wson=20framework=3A=20multi-degree=20ROAD M |Sender:=20; bh=a6lA07PZI5as0MdeNABKKR7opGl4CcoJKY33lGfP4ro=; b=g6eZ6/tHy7W9oNVLhxtK0IzKxQPxPO2hAcKUgco4VyZ9SRQ9XfwsFn+Pmj v7MGq86fesmu6X42uhocQj/Mt0oT0gZbW4/Gj9CcWwpdi7Y0nywnx3dVrnVN 7mNLCVzgqZ; Authentication-Results: ams-dkim-1; header.From=giomarti@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: [CCAMP] rwa wson framework: multi-degree ROADM 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, 15 Sep 2009 15:25:24 -0000 Hi Greg & WSONers, well, I saw you just suggest a last call request but I was wondering about representing a more general case of ROAM in section 3.3.1 The ID currently represent a 2 degree ROADM but looks to me a very specific case so I'm asking if it's ok adding a 4 degree ROADM as well. Here just a rough idea starting from your current picture +---------------------+ Line side-1 ingress --->| |---> Line side-2 egress Line side-1 egress <---| |<--- Line side-2 ingress | ROADM | Line side-3 ingress --->| |---> Line side-4 egress Line side-3 egress <---| |<--- Line side-4 ingress | | +---------------------+ | | | | o o o o | | | | | | | | O O O O | | | | Tributary Side: Drop (egress) Add (ingress) 1/ line sides likely have ingress and egress. 2/ Tributaries might be associated to sides but I would consider that as switching constrain. Does the switching matrix will apply in the same way, become an 8x8 right?. Any thoughts about? Cheers G From root@core3.amsl.com Tue Sep 15 08:30:03 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 11F453A6A4E; Tue, 15 Sep 2009 08:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090915153003.11F453A6A4E@core3.amsl.com> Date: Tue, 15 Sep 2009 08:30:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-mpls-graceful-shutdown-12.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2009 15:30:03 -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: March 14, 2010 September 15, 2009 Author(s) : Z. Ali, et al. Filename : draft-ietf-ccamp-mpls-graceful-shutdown-12.txt Pages : 10 Date : 2009-09-15 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-12.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-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-15082322.I-D@ietf.org> --NextPart-- From gregb@grotto-networking.com Tue Sep 15 08:46:32 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38FF93A6B7F for ; Tue, 15 Sep 2009 08:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.350, 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 ae5u65G-pK+T for ; Tue, 15 Sep 2009 08:46:31 -0700 (PDT) Received: from pro46.abac.com (pro46.abac.com [66.226.64.47]) by core3.amsl.com (Postfix) with ESMTP id 4D4583A6B98 for ; Tue, 15 Sep 2009 08:46:31 -0700 (PDT) Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id n8FFlB7A056037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Sep 2009 08:47:12 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <4AAFB6FF.2060301@grotto-networking.com> Date: Tue, 15 Sep 2009 08:47:11 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Giovanni Martinelli References: <4AAFB210.8000802@cisco.com> In-Reply-To: <4AAFB210.8000802@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ccamp@ietf.org Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM 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, 15 Sep 2009 15:46:32 -0000 Hi Giovanni, in the example given in section 5 (thanks to Dirk) we have multi-degree ROADMs. In section 3.3.1 we do mention higher degree ROADMs but refer readers to another draft. Hmm, maybe we should also point them to section 5. While I don't mind adding another picture, I think the chairs will be more interested in us reducing the length of the document than expanding it ;-) . Cheers Greg Giovanni Martinelli wrote: > Hi Greg & WSONers, > > well, I saw you just suggest a last call request but I was wondering > about representing a more general case of ROAM in section 3.3.1 > > The ID currently represent a 2 degree ROADM but looks to me a very > specific case so I'm asking if it's ok adding a 4 degree ROADM as well. > > > Here just a rough idea starting from your current picture > > +---------------------+ Line side-1 ingress > --->| |---> Line side-2 egress > Line side-1 egress <---| |<--- Line side-2 ingress > | ROADM | > Line side-3 ingress --->| |---> Line side-4 egress > Line side-3 egress <---| |<--- Line side-4 ingress > | | > +---------------------+ > | | | | o o o o > | | | | | | | | > O O O O | | | | > Tributary Side: Drop (egress) Add (ingress) > > > 1/ line sides likely have ingress and egress. > > > 2/ Tributaries might be associated to sides but I would consider that > as switching constrain. > > Does the switching matrix will apply in the same way, become an 8x8 > right?. > > Any thoughts about? > > > Cheers > G > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From lberger@labn.net Tue Sep 15 13:20:55 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FDE03A6875 for ; Tue, 15 Sep 2009 13:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=0.233, 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 0zuuOLQCD53o for ; Tue, 15 Sep 2009 13:20:53 -0700 (PDT) Received: from outbound-mail-117.bluehost.com (outbound-mail-117.bluehost.com [69.89.22.17]) by core3.amsl.com (Postfix) with SMTP id AC3013A6A90 for ; Tue, 15 Sep 2009 13:20:53 -0700 (PDT) Received: (qmail 12078 invoked by uid 0); 15 Sep 2009 20:21:41 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy3.bluehost.com with SMTP; 15 Sep 2009 20:21:41 -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=GVkMIinzWdylZzz6PSr6VpAfBVQwm8RaaVhTZakzlfGBZrpj4D79e2yTho1Rrn6+3lOiQZZqAj6Z+0skBQBwz2pKEJiO+8FIO0xB80XfK2dQgQ8XDoROzJvZU8r93cJU; 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 1MneWy-0001qX-Ve; Tue, 15 Sep 2009 14:21:41 -0600 Message-ID: <4AAFF757.4060102@labn.net> Date: Tue, 15 Sep 2009 16:21:43 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Weiqiang Sun References: <4AA6C495.4080306@labn.net> <4AAACA4E.3040006@labn.net> In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: draft-ietf-ccamp-lsp-dppm@tools.ietf.org, ccamp@ietf.org Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm 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, 15 Sep 2009 20:20:55 -0000 Weiqiang, Please see below. On 9/15/2009 1:23 AM, Weiqiang Sun wrote: > Hi Lou, > > Thank you for the comments. Please see below. > > Best regards, > Weiqiang > > -- > Weiqiang Sun > Shanghai Jiao Tong University > http://front.sjtu.edu.cn/~sunwq/ > > -------------------------------------------------- > From: "Lou Berger" > Sent: Saturday, September 12, 2009 6:08 AM > To: > Cc: > Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm > >> Authors, >> >> The following are LC comments. There are a couple of followup points >> from the 1st LC and then a slew of non-technical/editorial comments. >> >> - I'm happy to see additional RFC2119 directives to match your >> desired document track. Don't you think it would be worthwhile >> to add directives on what reporting is needed for the metrics >> actually being measured? As I read it, only bounds are reported. >> This really doesn't seem to make sense. Am I missing something? >> > Maybe we can change the text into: > ``In practice, the upper bound should be chosen carefully and the value > MUST > be reported along with the metric itself." > Do you think it is helpful? How about (section 4-8): In practice, the upper bound should be chosen carefully. o All collected metrics together with the selected upper bound MUST be reported. Section 9, 10, 11,12 ,13 : o All collected metrics together with the selected parameters MUST be reported. > >> - I think Section 14.4 addresses much of my earlier comment on >> "undefined" values. I still have a couple of additional points: >> >> Don't you think it would be worthwhile to also report the Success >> Count as an integer? (as percentages can yield rounding errors.) > Please be noted that we already have the Failure Count(14.4.1). Success > Count can be easily deduced from: ``the number of all values in a sample - > Failure Count". Reporting the Success Count seems a bit redundant, > when the Failure count is far more important and necessary. I don't see where the total number of requests in a sample is described. If it is, then I agree that Success Count isn't needed. > >> >> As part of the rfc2119 language you're adding related to the >> reporting of metrics defined in section 14, I suggest that you >> highlight the easily missed point of "we only consider the >> finite values" by including "success" as part of the metric >> name. I'm not sure on exact phrasing as this will depend on >> how you write the language. > Since the undefined values are properly treated in section 14 using the > rfc2119 language, maybe we can just drop > the sentence "In the following discussion, we only consider the finite > values." How do you think? > If total or success count are added, this is fine. >> >> Is there a reason that you included Minimum and Median in >> Section 14, but not maximum? > Minimum and Median values are generally more stable than maximum in a large > measurement and can provide valuable sights to the DUT/SUT. Sure, but maximums provide an important view into what can be expected from the system. Without the max value there is no way to understand worst case behavior. I think it's worth including. > We do have a bunch of other statistics that are not yet included in the > document. What we can offer is a suggested sub-set, rather than a whole > set. > The current selection is based on rfc2679 and rfc2681. > well, seems like you should add a caveate along the lines of 2679, i.e., "These statistics are offered mostly to be illustrative of what could be done." >> >> General comments: > Many thanks for the comments below. We will make the changes accordingly. > Thanks, Lou From wwwrun@core3.amsl.com Wed Sep 16 08:48:48 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9A9313A6A0D; Wed, 16 Sep 2009 08:48:48 -0700 (PDT) From: Deborah Brungard(IETF CCAMP WG) To: Peter.Stassar@ties.itu.int, Malcolm.Betts@huawei.com, hklam@alcatel-lucent.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090916154848.9A9313A6A0D@core3.amsl.com> Date: Wed, 16 Sep 2009 08:48:48 -0700 (PDT) Cc: ccamp@ietf.org, sjtrowbridge@alcatel-lucent.com, paf@cisco.com, Adrian.Farrel@huawei.com, rcallon@juniper.com, pce@ietf.org, pja@nortel.com, francesco.montalti@telecomitalia.it Subject: [CCAMP] New Liaison Statement, "WSON Impairment Work in CCAMP" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dbrungard@att.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 15:48:48 -0000 Title: WSON Impairment Work in CCAMP Submission Date: 2009-09-16 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=578 Please reply by 2009-10-30 From: Deborah Brungard(IETF CCAMP WG) To: ITU-T SG15 Question 6, Question 12, and Question 14(Peter.Stassar@ties.itu.int,Malcolm.Betts@huawei.com,hklam@alcatel-lucent.com) Cc: Greg.Jones@itu.int sjtrowbridge@alcatel-lucent.com francesco.montalti@telecomitalia.it pja@nortel.com paf@cisco.com Adrian.Farrel@huawei.com rcallon@juniper.com lberger@labn.net ccamp@ietf.org pce@ietf.org Reponse Contact: dbrungard@att.com Technical Contact: dbrungard@att.com Purpose: For action Body: The CCAMP Working Group of IETF thanks Question 12 for their liaison from the September 2008 meeting informing of their initiation of work to be done in cooperation with Question 6 on developing a network model for WSON which will include optical impairments. We would like to inform you of our progress in this area as documented in the CCAMP document "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments": http://www.ietf.org/id/draft-ietf-ccamp-wson-impairments-00.txt This document provides a framework for GMPLS protocols and mechanisms to support impairment aware routing and wavelength assignment. The deployment scenarios are based on the categories discussed at Question 6's Sunnyvale meeting: http://ifa.itu.int/t/2009/sg15/exchange/wp2/q6/Meetings/2009-03-Sunnyvale/Contributions/WD6-38.doc We would appreciate your consideration of this document in your work and would you please inform us of the scope of your work and the timelines. For CCAMP's impairment work, CCAMP is focused on scenarios where approximated impairment estimation using ITU-T defined parameters and approximation techniques (G.680) may be used. The objective of CCAMP work is to distribute the information which is needed to allow path computation and signaling of new paths. We would appreciate your input on the parameter information which is needed to be distributed by a control plane, to be used by either a node for internal path computation or a Path Computation Element, and its properties, so as to understand the control plane distribution requirements. In addition, we would appreciate your perspective on control plane modeling and implications with regard to ITU-T's G.872 OTN aspects e.g. OTN multi-layers (OTS, OMS, OCh), regenerators, and o/e/o (OCh, OTU, ODU). Best Regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs Attachment(s): No document has been attached From wwwrun@core3.amsl.com Wed Sep 16 10:25:04 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 788E33A6A96; Wed, 16 Sep 2009 10:25:04 -0700 (PDT) From: Deborah Brungard(IETF CCAMP WG) To: Peter.Stassar@ties.itu.int Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090916172504.788E33A6A96@core3.amsl.com> Date: Wed, 16 Sep 2009 10:25:04 -0700 (PDT) Cc: ccamp@ietf.org, paf@cisco.com, Adrian.Farrel@huawei.com, rcallon@juniper.com, pja@nortel.com, Francesco.Montalti@telecomitalia.it Subject: [CCAMP] New Liaison Statement, "ITU-T Recommendation G.697 Parameter Encoding" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dbrungard@att.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 17:25:04 -0000 Title: ITU-T Recommendation G.697 Parameter Encoding Submission Date: 2009-09-16 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=579 From: Deborah Brungard(IETF CCAMP WG) To: ITU-T SG15 Question 6(Peter.Stassar@ties.itu.int) Cc: Greg.Jones@itu.int Francesco.Montalti@telecomitalia.it pja@nortel.com paf@cisco.com Adrian.Farrel@huawei.com rcallon@juniper.com lberger@labn.net ccamp@ietf.org Reponse Contact: dbrungard@att.com Technical Contact: dbrungard@att.com Purpose: For action Body: The CCAMP Working Group of IETF thanks you for your time in meeting with members of CCAMP to discuss our WSON work at your Sunnyvale meeting. We would like to request your review of the CCAMP document �Generalized Labels for G.694 Lambda-Switching Capable Label Switching Routers�: http://www.ietf.org/id/draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.txt This document was updated based on our discussion at the Sunnyvale meeting on your proposed changes to G.697 (Appendix V on Parameter encoding). We would appreciate your review to ensure our understanding is correct on your proposed Wavelength ID field encoding for G.697. Would you please inform us if this proposed Appendix has been included in the revised G.697 planned for consent at this September�s SG15 Plenary meeting? As our document predates the decision to include this information in G.697, we plan to update it with reference to G.697. We would appreciate a response from this September�s meeting as we plan to last call this document in November. Best Regards, Lou Berger and Deborah Brungard IETF CCAMP Working Group Co-Chairs Attachment(s): No document has been attached From web-usrn@ISI.EDU Wed Sep 16 12:39:15 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F713A6820 for ; Wed, 16 Sep 2009 12:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.877 X-Spam-Level: X-Spam-Status: No, score=-16.877 tagged_above=-999 required=5 tests=[AWL=0.722, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zeid4SQD6j4n for ; Wed, 16 Sep 2009 12:39:14 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 1BC373A6805 for ; Wed, 16 Sep 2009 12:39:14 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n8GJdNfj026995; Wed, 16 Sep 2009 12:39:23 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n8GJdMxN026992; Wed, 16 Sep 2009 12:39:22 -0700 (PDT) Date: Wed, 16 Sep 2009 12:39:22 -0700 (PDT) Message-Id: <200909161939.n8GJdMxN026992@boreas.isi.edu> To: tnadeau@cisco.com, adrian@olddog.co.uk, rcallon@juniper.net, adrian.farrel@huawei.com, lberger@labn.net, dbrungard@att.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] [Technical Errata Reported] RFC4803 (1883) 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, 16 Sep 2009 19:39:15 -0000 The following errata report has been submitted for RFC4803, "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4803&eid=1883 -------------------------------------- Type: Technical Reported by: Vishwas Manral Section: MIB Original Text ------------- gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Period, in milliseconds, between sending Resource Reservation Protocol (RSVP) Hello messages on this interface. A value of 0 indicates that no Hello messages should be sent on this interface. This object is only valid if gmplsInterfaceSignalingCaps has no bits set or includes the rsvpGmpls bit." REFERENCE "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209, section 5. 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473, section 9.3." DEFVAL { 3000 } ::= { gmplsInterfaceEntry 2 } Corrected Text -------------- gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE SYNTAX Unsigned32 UNITS "milliseconds" MAX-ACCESS read-create STATUS current DESCRIPTION "Period, in milliseconds, between sending Resource Reservation Protocol (RSVP) Hello messages on this interface. A value of 0 indicates that no Hello messages should be sent on this interface. This object is only valid if gmplsInterfaceSignalingCaps has no bits set or includes the rsvpGmpls bit." REFERENCE "1. RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC 3209, section 5. 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473, section 9.3." DEFVAL { 5 } ::= { gmplsInterfaceEntry 2 } Notes ----- The default value is changed. The default value specified in the RFC is 5ms. Section 5.3 states: This value MAY be configured on a per neighbor basis. The default value is 5 ms. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4803 (draft-ietf-ccamp-gmpls-lsr-mib-15) -------------------------------------- Title : Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base Publication Date : February 2007 Author(s) : T. Nadeau, Ed., A. Farrel, Ed. Category : PROPOSED STANDARD Source : Common Control and Measurement Plane Area : Routing Stream : IETF Verifying Party : IESG From sunwq@MIT.EDU Thu Sep 17 00:38:07 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D683B3A6A3D for ; Thu, 17 Sep 2009 00:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o144nvbo7O08 for ; Thu, 17 Sep 2009 00:38:06 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 1DEA53A6982 for ; Thu, 17 Sep 2009 00:38:05 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n8H7crpa025541; Thu, 17 Sep 2009 03:38:53 -0400 (EDT) Received: from APC ([202.120.39.240]) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n8H7chHY002194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Sep 2009 03:38:47 -0400 (EDT) Message-ID: <896C8760F85A43F2927F7BD0E284DC79@mit.edu> From: "Weiqiang Sun" To: "Lou Berger" References: <4AA6C495.4080306@labn.net> <4AAACA4E.3040006@labn.net> <4AAFF757.4060102@labn.net> In-Reply-To: <4AAFF757.4060102@labn.net> Date: Thu, 17 Sep 2009 15:38:36 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Cc: draft-ietf-ccamp-lsp-dppm@tools.ietf.org, ccamp@ietf.org Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm 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, 17 Sep 2009 07:38:07 -0000 Lou, Please see below. -------------------------------------------------- From: "Lou Berger" Sent: Wednesday, September 16, 2009 4:21 AM To: "Weiqiang Sun" Cc: ; Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm > Weiqiang, > Please see below. > > On 9/15/2009 1:23 AM, Weiqiang Sun wrote: >> Hi Lou, >> >> Thank you for the comments. Please see below. >> >> Best regards, >> Weiqiang >> >> -- >> Weiqiang Sun >> Shanghai Jiao Tong University >> http://front.sjtu.edu.cn/~sunwq/ >> >> -------------------------------------------------- >> From: "Lou Berger" >> Sent: Saturday, September 12, 2009 6:08 AM >> To: >> Cc: >> Subject: Re: [CCAMP] 2nd Working group last call: >> draft-ietf-ccamp-lsp-dppm >> >>> Authors, >>> >>> The following are LC comments. There are a couple of followup points >>> from the 1st LC and then a slew of non-technical/editorial comments. >>> >>> - I'm happy to see additional RFC2119 directives to match your >>> desired document track. Don't you think it would be worthwhile >>> to add directives on what reporting is needed for the metrics >>> actually being measured? As I read it, only bounds are reported. >>> This really doesn't seem to make sense. Am I missing something? >>> >> Maybe we can change the text into: >> ``In practice, the upper bound should be chosen carefully and the value >> MUST >> be reported along with the metric itself." >> Do you think it is helpful? > > How about (section 4-8): > In practice, the upper bound should be chosen carefully. > > o All collected metrics together with the selected upper bound MUST > be reported. > > Section 9, 10, 11,12 ,13 : > > o All collected metrics together with the selected parameters MUST > be reported. The suggested text sounds good to me. > >> >>> - I think Section 14.4 addresses much of my earlier comment on >>> "undefined" values. I still have a couple of additional points: >>> >>> Don't you think it would be worthwhile to also report the Success >>> Count as an integer? (as percentages can yield rounding errors.) >> Please be noted that we already have the Failure Count(14.4.1). Success >> Count can be easily deduced from: ``the number of all values in a >> sample - >> Failure Count". Reporting the Success Count seems a bit redundant, >> when the Failure count is far more important and necessary. > > I don't see where the total number of requests in a sample is described. > If it is, then I agree that Success Count isn't needed. Once a sample is obtained and reported, the total number is then fixed. Do you think it is necessary to give an explicit description of the total number of values in a sample? It is so obvious to me... > >> >>> >>> As part of the rfc2119 language you're adding related to the >>> reporting of metrics defined in section 14, I suggest that you >>> highlight the easily missed point of "we only consider the >>> finite values" by including "success" as part of the metric >>> name. I'm not sure on exact phrasing as this will depend on >>> how you write the language. >> Since the undefined values are properly treated in section 14 using the >> rfc2119 language, maybe we can just drop >> the sentence "In the following discussion, we only consider the finite >> values." How do you think? >> > > If total or success count are added, this is fine. Please see above. > >>> >>> Is there a reason that you included Minimum and Median in >>> Section 14, but not maximum? >> Minimum and Median values are generally more stable than maximum in a >> large >> measurement and can provide valuable sights to the DUT/SUT. > > Sure, but maximums provide an important view into what can be expected > from the system. Without the max value there is no way to understand > worst case behavior. I think it's worth including. Yes it may be helpful, but it might also be dangerous to say the maximum reflects the worst case behavior, when all reported values are bounded (by a preset upper bound). In this sense the ``maximum" by its name may be misleading... > >> We do have a bunch of other statistics that are not yet included in the >> document. What we can offer is a suggested sub-set, rather than a whole >> set. >> The current selection is based on rfc2679 and rfc2681. >> > > well, seems like you should add a caveate along the lines of 2679, i.e., > "These statistics are offered mostly to be illustrative of what could be > done." Sounds good to me. Thanks always, -weiqiang > >>> >>> General comments: >> Many thanks for the comments below. We will make the changes accordingly. >> > > Thanks, > Lou > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From giomarti@cisco.com Thu Sep 17 00:58:18 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CBEE3A6933 for ; Thu, 17 Sep 2009 00:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAcgbyICQUcM for ; Thu, 17 Sep 2009 00:58:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D321D3A68B7 for ; Thu, 17 Sep 2009 00:58:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIAAKuIsUqQ/uCLe2dsb2JhbACbJwEBFiQGqVaITgGQNQWEGA X-IronPort-AV: E=Sophos;i="4.44,402,1249257600"; d="scan'208";a="49575083" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Sep 2009 07:59:07 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8H7x6T3015198; Thu, 17 Sep 2009 09:59:06 +0200 Received: from [144.254.166.78] (mnza1-dhcp-vl301-144-254-166-78.cisco.com [144.254.166.78]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8H7x6ON003613; Thu, 17 Sep 2009 07:59:06 GMT Message-ID: <4AB1EC48.2050407@cisco.com> Date: Thu, 17 Sep 2009 09:59:04 +0200 From: Giovanni Martinelli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Greg Bernstein References: <4AAFB210.8000802@cisco.com> <4AAFB6FF.2060301@grotto-networking.com> In-Reply-To: <4AAFB6FF.2060301@grotto-networking.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2834; t=1253174346; x=1254038346; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=giomarti@cisco.com; z=From:=20Giovanni=20Martinelli=20 |Subject:=20Re=3A=20[CCAMP]=20rwa=20wson=20framework=3A=20m ulti-degree=20ROADM |Sender:=20; bh=zVwQ0EqlEiKhlBYsR9ZUaPv6B2Jg/r/rSctlS60v3ZU=; b=AT51zirjYe3tG8dJGfTYhrGsiDjl5+xoyQoALbvHyo3aM0UUOclTCGriss ks06o2HbdCmuyk+Amcy0VvTUDC9ntXp/h6n/fEKecFhAXhwAhzG6qpLoM6NB Q4IIugMYPQ; Authentication-Results: ams-dkim-2; header.From=giomarti@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ccamp@ietf.org Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM 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, 17 Sep 2009 07:58:18 -0000 Hi Greg, Greg Bernstein wrote: > Hi Giovanni, in the example given in section 5 (thanks to Dirk) we > have multi-degree ROADMs. In section 3.3.1 we do mention higher degree > ROADMs but refer readers to another draft. Hmm, maybe we should also > point them to section 5. um well Section 5 provide more a high level overview and the scope is a bit different while the other reference at the end still contain 2 degree roadm (unless I'm missing something) This section was providing details about how a roadm is presented and the respective connectivity matrix (while in other examples the connectivity matrix only shows what is important for the example itself). To me this is important to show how exactly every roadm can be represented (and I guess generalizing from 4 to n will be clearer than doing from 2 to n degree) and the size of the matrix (then how is sparse is another topic). > While I don't mind adding another picture, I think the chairs will be > more interested in us reducing the length of the document than > expanding it ;-) . > well hope it's not the main criteria (we can always shot for the longest RFC) ;-) Cheers G > Cheers > > Greg > > Giovanni Martinelli wrote: >> Hi Greg & WSONers, >> >> well, I saw you just suggest a last call request but I was wondering >> about representing a more general case of ROAM in section 3.3.1 >> >> The ID currently represent a 2 degree ROADM but looks to me a very >> specific case so I'm asking if it's ok adding a 4 degree ROADM as well. >> >> >> Here just a rough idea starting from your current picture >> >> +---------------------+ Line side-1 ingress >> --->| |---> Line side-2 egress >> Line side-1 egress <---| |<--- Line side-2 >> ingress >> | ROADM | >> Line side-3 ingress --->| |---> Line side-4 egress >> Line side-3 egress <---| |<--- Line side-4 >> ingress >> | | >> +---------------------+ >> | | | | o o o o >> | | | | | | | | >> O O O O | | | | >> Tributary Side: Drop (egress) Add (ingress) >> >> >> 1/ line sides likely have ingress and egress. >> >> >> 2/ Tributaries might be associated to sides but I would consider that >> as switching constrain. >> >> Does the switching matrix will apply in the same way, become an 8x8 >> right?. >> >> Any thoughts about? >> >> >> Cheers >> G >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > From lberger@labn.net Thu Sep 17 04:04:47 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532EE28C202 for ; Thu, 17 Sep 2009 04:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=0.229, 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 CNnSauA5G4PO for ; Thu, 17 Sep 2009 04:04:46 -0700 (PDT) Received: from outbound-mail-13.bluehost.com (outbound-mail-13.bluehost.com [69.89.18.113]) by core3.amsl.com (Postfix) with SMTP id 7907E3A6AA1 for ; Thu, 17 Sep 2009 04:04:46 -0700 (PDT) Received: (qmail 7714 invoked by uid 0); 17 Sep 2009 11:05:37 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy1.bluehost.com with SMTP; 17 Sep 2009 11:05:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=gOuuEGRZ3qh7xNt6iepP0kmTACt9Lko5a+oq5QCWYK6sF9SMxUOIEkpA1TOq0EMY+9CJgP9JDUD1vPEHqiqunVsE1MECqKbraWu+Fcuojra2v22Mp72c+N3B1MryqsZg; 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 1MoEnx-0006nU-6x; Thu, 17 Sep 2009 05:05:37 -0600 Message-ID: <4AB21803.70201@labn.net> Date: Thu, 17 Sep 2009 07:05:39 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Weiqiang Sun References: <4AA6C495.4080306@labn.net> <4AAACA4E.3040006@labn.net> <4AAFF757.4060102@labn.net> <896C8760F85A43F2927F7BD0E284DC79@mit.edu> In-Reply-To: <896C8760F85A43F2927F7BD0E284DC79@mit.edu> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: draft-ietf-ccamp-lsp-dppm@tools.ietf.org, ccamp@ietf.org Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm 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, 17 Sep 2009 11:04:47 -0000 Weiqiang, It seems we're left with two open topics: 1) I propose addressing the total count topic using text along the lines of: (section 4-8): o All collected metrics together with the total number of values (both real and undefined) and the selected upper bound MUST be reported. Section 9, 10, 11,12 ,13 : o All collected metrics together with the total number of values (both real and undefined) and the selected parameters MUST be reported. 2) >>>> Is there a reason that you included Minimum and Median in >>>> Section 14, but not maximum? >>> Minimum and Median values are generally more stable than maximum in a >>> large >>> measurement and can provide valuable sights to the DUT/SUT. >> >> Sure, but maximums provide an important view into what can be expected >> from the system. Without the max value there is no way to understand >> worst case behavior. I think it's worth including. > Yes it may be helpful, but it might also be dangerous to say the maximum > reflects the worst case behavior, when all reported values are bounded > (by a preset upper bound). > In this sense the ``maximum" by its name may be misleading... > Well this depends on the selected upper bound. Also, yes statistics *can* be misread, but if the data isn't present there's no way for the results to be properly interpreted. Lou From sunwq@MIT.EDU Thu Sep 17 07:14:35 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6EFC3A69BD for ; Thu, 17 Sep 2009 07:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHCDm66pEkBK for ; Thu, 17 Sep 2009 07:14:34 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id BC1D03A6A27 for ; Thu, 17 Sep 2009 07:14:34 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n8HEFM7p025054; Thu, 17 Sep 2009 10:15:22 -0400 (EDT) Received: from APC (125.146.38.58.broad.xw.sh.dynamic.163data.com.cn [58.38.146.125] (may be forged)) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n8HEFGfY015596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 17 Sep 2009 10:15:20 -0400 (EDT) Message-ID: From: "Weiqiang Sun" To: "Lou Berger" References: <4AA6C495.4080306@labn.net> <4AAACA4E.3040006@labn.net> <4AAFF757.4060102@labn.net> <896C8760F85A43F2927F7BD0E284DC79@mit.edu> <4AB21803.70201@labn.net> In-Reply-To: <4AB21803.70201@labn.net> Date: Thu, 17 Sep 2009 22:14:57 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Cc: draft-ietf-ccamp-lsp-dppm@tools.ietf.org, ccamp@ietf.org Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm 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, 17 Sep 2009 14:14:35 -0000 Hi Lou, I agree with you on 1. As for 2, what I can come up with is the text below. I can not persuade myself to put it in the draft :(. Maybe you have better ways of putting it... 14.x. The Maximum of Metric The maximum of metric is the maximum of all the dT values in the sample. In computing this, undefined values MUST NOT be counted in. Note that this means that the maximum could thus be undefined if all the dT values are undefined. In addition, the metric maximum SHOULD be set to undefined if the sample is empty. It also must be noted that exceptionally a measurement may result in a value that is greater than the upper bound and is thus deemed undefined. Because of this, the maximum of metric must be used with caution. Thanks, Weiqiang -------------------------------------------------- From: "Lou Berger" Sent: Thursday, September 17, 2009 7:05 PM To: "Weiqiang Sun" Cc: ; Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm > Weiqiang, > It seems we're left with two open topics: > > 1) I propose addressing the total count topic using text along the lines > of: > > (section 4-8): > o All collected metrics together with the total number of values > (both real and undefined) and the selected upper bound MUST be > reported. > > Section 9, 10, 11,12 ,13 : > > o All collected metrics together with the total number of values > (both real and undefined) and the selected parameters MUST be > reported. > > 2) > >>>>> Is there a reason that you included Minimum and Median in >>>>> Section 14, but not maximum? >>>> Minimum and Median values are generally more stable than maximum in a >>>> large >>>> measurement and can provide valuable sights to the DUT/SUT. >>> >>> Sure, but maximums provide an important view into what can be expected >>> from the system. Without the max value there is no way to understand >>> worst case behavior. I think it's worth including. >> Yes it may be helpful, but it might also be dangerous to say the maximum >> reflects the worst case behavior, when all reported values are bounded >> (by a preset upper bound). >> In this sense the ``maximum" by its name may be misleading... >> > > Well this depends on the selected upper bound. Also, yes statistics > *can* be misread, but if the data isn't present there's no way for the > results to be properly interpreted. > > Lou > From loa@pi.nu Fri Sep 18 00:20:59 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA69C3A687E; Fri, 18 Sep 2009 00:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.191 X-Spam-Level: X-Spam-Status: No, score=-1.191 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ozJoYIi7eGE; Fri, 18 Sep 2009 00:20:59 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id D94CC3A684B; Fri, 18 Sep 2009 00:20:58 -0700 (PDT) Received: from [192.168.0.100] (h133n2fls33o883.telia.com [217.208.62.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id BEF58D4048; Fri, 18 Sep 2009 09:21:48 +0200 (CEST) Message-ID: <4AB33508.9070105@pi.nu> Date: Fri, 18 Sep 2009 09:21:44 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org Subject: [CCAMP] wg last call on the mpls-tp-gach- gal draft ended. 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, 18 Sep 2009 07:20:59 -0000 All, the working group last call on draft-ietf-mpls-tp-gach-dcn-05.txt has ended and we have received comments from ITU-T (see https://datatracker.ietf.org/liaison/581/). Could the authors please address teh comments and re-publish the draft. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From danli@huawei.com Fri Sep 18 02:23:05 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3F33A698A for ; Fri, 18 Sep 2009 02:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.544 X-Spam-Level: X-Spam-Status: No, score=0.544 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qaNs6ZdHJBJ for ; Fri, 18 Sep 2009 02:23:04 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 247D63A67A2 for ; Fri, 18 Sep 2009 02:23:04 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ500CI7U3KL7@szxga03-in.huawei.com> for ccamp@ietf.org; Fri, 18 Sep 2009 17:23:44 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ5001J9U3KN9@szxga03-in.huawei.com> for ccamp@ietf.org; Fri, 18 Sep 2009 17:23:44 +0800 (CST) Received: from l37133a ([10.70.77.63]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ500L37U3J8C@szxml06-in.huawei.com> for ccamp@ietf.org; Fri, 18 Sep 2009 17:23:44 +0800 (CST) Date: Fri, 18 Sep 2009 17:23:43 +0800 From: Dan Li To: ccamp@ietf.org Message-id: <008a01ca3841$b7af7740$3f4d460a@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_duNiSdAcYc3auD/XRFMuWw)" X-Priority: 3 X-MSMail-priority: Normal Subject: [CCAMP] draft-li-ccamp-lmp-behavior-negotiation-00.txt has been published 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, 18 Sep 2009 09:23:05 -0000 This is a multi-part message in MIME format. --Boundary_(ID_duNiSdAcYc3auD/XRFMuWw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hello, During the WG LC for draft-ietf-ccamp-confirm-data-channel-status-07.txt, we have idenitifed a basic issue in LMP with respect to backward compatibility. In particular, LMP does not have a basic mechanism to allow an LMP implementation to determine when a neighbor supports new/extended functionality. We have agreed that a future standalone document is needed. Now, the draft has been provided! http://tools.ietf.org/id/draft-li-ccamp-lmp-behavior-negotiation-00.txt Abstract: The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in Generalized Multiprotocol Label Switching (GMPLS) networks. Various proposals have been advanced to provide extensions to the base LMP specification. This document provides a generic procedure for LMP implementations that do not recognize or do not support any one of these extensions. Please take a look and let me know your advice! Thanks, Dan --Boundary_(ID_duNiSdAcYc3auD/XRFMuWw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hello,

During the WG LC for draft-ietf-ccamp-confirm-data-channel-status-07.txt, we have idenitifed a basic issue in LMP with respect to backward compatibility. In particular, LMP does not have a basic mechanism to allow an LMP implementation to determine when a neighbor supports new/extended functionality. We have agreed that a future standalone document is needed.

Now, the draft has been provided! http://tools.ietf.org/id/draft-li-ccamp-lmp-behavior-negotiation-00.txt

Abstract:

The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in Generalized Multiprotocol Label Switching (GMPLS) networks. Various proposals have been advanced to provide extensions to the base LMP specification. This document provides a generic procedure for LMP implementations that do not recognize or do not support any one of these extensions.

Please take a look and let me know your advice!

Thanks,

Dan


 

--Boundary_(ID_duNiSdAcYc3auD/XRFMuWw)-- From lberger@labn.net Fri Sep 18 12:50:52 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E47528C186 for ; Fri, 18 Sep 2009 12:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6DZnhppHlpF for ; Fri, 18 Sep 2009 12:50:51 -0700 (PDT) Received: from outbound-mail-143.bluehost.com (outbound-mail-143.bluehost.com [67.222.38.33]) by core3.amsl.com (Postfix) with SMTP id 06D8C3A68F4 for ; Fri, 18 Sep 2009 12:50:51 -0700 (PDT) Received: (qmail 22630 invoked by uid 0); 18 Sep 2009 19:51:45 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy5.bluehost.com with SMTP; 18 Sep 2009 19:51:45 -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=DRwlT0uyB1/yXspbN8KE8u0rbGxX/6dTDah3UwDhAaKiKeetPUYJSkvuezvSPr7gI9z0vIdvD3x8zZYoZbof0Yl9IW6BR9BlA6SH+iM38DTX9E55u6yH6BDGKle7bEdY; 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 1MojUf-0001KO-EQ; Fri, 18 Sep 2009 13:51:45 -0600 Message-ID: <4AB3E4D6.90807@labn.net> Date: Fri, 18 Sep 2009 15:51:50 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Weiqiang Sun References: <4AA6C495.4080306@labn.net> <4AAACA4E.3040006@labn.net> <4AAFF757.4060102@labn.net> <896C8760F85A43F2927F7BD0E284DC79@mit.edu> <4AB21803.70201@labn.net> In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: draft-ietf-ccamp-lsp-dppm@tools.ietf.org, ccamp@ietf.org Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm 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, 18 Sep 2009 19:50:52 -0000 Weiqiang, How about something along the lines of : 14.x. The Maximum of Metric The maximum of metric is the maximum of all the dT values in the sample. In computing this, undefined values MUST NOT be included. Note that this means that measurements that exceed the upper bound are not reported in this statistic. This is an important consideration when evaluating the maximum when the number of undefined measurements is non-zero. Lou On 9/17/2009 10:14 AM, Weiqiang Sun wrote: > Hi Lou, > > I agree with you on 1. > As for 2, what I can come up with is the text below. I can not persuade > myself to put it in the draft :(. Maybe you have better ways of putting > it... > > 14.x. The Maximum of Metric > > The maximum of metric is the maximum of all the dT values in the > sample. In computing this, undefined values MUST NOT be counted in. > Note that this means that the maximum could thus be undefined if all > the dT values are undefined. In addition, the metric maximum SHOULD > be set to undefined if the sample is empty. > > It also must be noted that exceptionally a measurement may result in a > value that is greater than the upper bound and is thus deemed undefined. > Because of this, the maximum of metric must be used with caution. > > Thanks, > Weiqiang > > -------------------------------------------------- > From: "Lou Berger" > Sent: Thursday, September 17, 2009 7:05 PM > To: "Weiqiang Sun" > Cc: ; > Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm > >> Weiqiang, >> It seems we're left with two open topics: >> >> 1) I propose addressing the total count topic using text along the >> lines of: >> >> (section 4-8): >> o All collected metrics together with the total number of values >> (both real and undefined) and the selected upper bound MUST be >> reported. >> >> Section 9, 10, 11,12 ,13 : >> >> o All collected metrics together with the total number of values >> (both real and undefined) and the selected parameters MUST be >> reported. >> >> 2) >> >>>>>> Is there a reason that you included Minimum and Median in >>>>>> Section 14, but not maximum? >>>>> Minimum and Median values are generally more stable than maximum in a >>>>> large >>>>> measurement and can provide valuable sights to the DUT/SUT. >>>> >>>> Sure, but maximums provide an important view into what can be expected >>>> from the system. Without the max value there is no way to understand >>>> worst case behavior. I think it's worth including. >>> Yes it may be helpful, but it might also be dangerous to say the maximum >>> reflects the worst case behavior, when all reported values are bounded >>> (by a preset upper bound). >>> In this sense the ``maximum" by its name may be misleading... >>> >> >> Well this depends on the selected upper bound. Also, yes statistics >> *can* be misread, but if the data isn't present there's no way for the >> results to be properly interpreted. >> >> Lou >> > > > From ylee@huawei.com Fri Sep 18 12:55:43 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF5703A6847 for ; Fri, 18 Sep 2009 12:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgPdKwqcn9nf for ; Fri, 18 Sep 2009 12:55:42 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id D44EB3A6923 for ; Fri, 18 Sep 2009 12:55:42 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQ600M49NEAV3@usaga02-in.huawei.com> for ccamp@ietf.org; Fri, 18 Sep 2009 12:56:35 -0700 (PDT) Received: from L73682 ([10.124.12.76]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQ600JXUNE7LQ@usaga02-in.huawei.com> for ccamp@ietf.org; Fri, 18 Sep 2009 12:56:34 -0700 (PDT) Date: Fri, 18 Sep 2009 14:56:31 -0500 From: Young Lee In-reply-to: <4AB1EC48.2050407@cisco.com> To: 'Giovanni Martinelli' Message-id: <002001ca389a$1e7eb5a0$4c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Aco3bMx5EppOp3ktSsuUZkv1e2TdoQBKLuyg References: <4AAFB210.8000802@cisco.com> <4AAFB6FF.2060301@grotto-networking.com> <4AB1EC48.2050407@cisco.com> Cc: ccamp@ietf.org Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM 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, 18 Sep 2009 19:55:44 -0000 Hi Giovanni, We have added 4-degree ROADM figure and connectivity matrix per your suggestion in the draft. Below is tentative text we have added in Section 3.3.1. I hope this would satisfy your request. Thanks. Young ---------------------------------------------------------------- Ingress 1 +---------------+ +---------------+ Egress 1 ----> | | -->| |----> Ingress 2 | | | | Egress 2 ----> | | -->| |----> +---------------+ +---------------+ | | | | | | O O O O O O | | | | | | | | | | | | O O O O O O | | | | | | E3 E4 E5 E6 E7 E8 I3 I4 I5 I6 I7 I8 Triburary Side Drop Add Figure 2 Degree-4 ROADM For the ROADM of Figure 2 the switched connectivity matrix can be expressed as follows. Note that this ROADM is based on per port add/drop. Ingress Egress Port Port #1 #2 #3 #4 #5 #6 #7 #8 -------------- #1: 1 1 0 0 0 1 1 1 #2 1 1 1 1 1 0 0 0 A = #3 0 1 0 0 0 0 0 0 #4 0 1 0 0 0 0 0 0 #5 0 1 0 0 0 0 0 0 #6 1 0 0 0 0 0 0 0 #7 1 0 0 0 0 0 0 0 #8 1 0 0 0 0 0 0 0 Where egress ports 3-5 are drop ports from Ingress 2 and egress ports 6-8 are drop ports from Ingress 1 and ingress ports 3-5 are add ports to Egress 2, ingress ports 6-8 are add ports to Egress 1. -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Giovanni Martinelli Sent: Thursday, September 17, 2009 2:59 AM To: Greg Bernstein Cc: ccamp@ietf.org Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM Hi Greg, Greg Bernstein wrote: > Hi Giovanni, in the example given in section 5 (thanks to Dirk) we > have multi-degree ROADMs. In section 3.3.1 we do mention higher degree > ROADMs but refer readers to another draft. Hmm, maybe we should also > point them to section 5. um well Section 5 provide more a high level overview and the scope is a bit different while the other reference at the end still contain 2 degree roadm (unless I'm missing something) This section was providing details about how a roadm is presented and the respective connectivity matrix (while in other examples the connectivity matrix only shows what is important for the example itself). To me this is important to show how exactly every roadm can be represented (and I guess generalizing from 4 to n will be clearer than doing from 2 to n degree) and the size of the matrix (then how is sparse is another topic). > While I don't mind adding another picture, I think the chairs will be > more interested in us reducing the length of the document than > expanding it ;-) . > well hope it's not the main criteria (we can always shot for the longest RFC) ;-) Cheers G > Cheers > > Greg > > Giovanni Martinelli wrote: >> Hi Greg & WSONers, >> >> well, I saw you just suggest a last call request but I was wondering >> about representing a more general case of ROAM in section 3.3.1 >> >> The ID currently represent a 2 degree ROADM but looks to me a very >> specific case so I'm asking if it's ok adding a 4 degree ROADM as well. >> >> >> Here just a rough idea starting from your current picture >> >> +---------------------+ Line side-1 ingress >> --->| |---> Line side-2 egress >> Line side-1 egress <---| |<--- Line side-2 >> ingress >> | ROADM | >> Line side-3 ingress --->| |---> Line side-4 egress >> Line side-3 egress <---| |<--- Line side-4 >> ingress >> | | >> +---------------------+ >> | | | | o o o o >> | | | | | | | | >> O O O O | | | | >> Tributary Side: Drop (egress) Add (ingress) >> >> >> 1/ line sides likely have ingress and egress. >> >> >> 2/ Tributaries might be associated to sides but I would consider that >> as switching constrain. >> >> Does the switching matrix will apply in the same way, become an 8x8 >> right?. >> >> Any thoughts about? >> >> >> Cheers >> G >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From loa@pi.nu Sat Sep 19 03:43:41 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0619F3A6946; Sat, 19 Sep 2009 03:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 vL9qZCiIURtR; Sat, 19 Sep 2009 03:43:39 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id A06353A6883; Sat, 19 Sep 2009 03:43:38 -0700 (PDT) Received: from [192.168.0.100] (h133n2fls33o883.telia.com [217.208.62.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 34994D4048; Sat, 19 Sep 2009 12:44:33 +0200 (CEST) Message-ID: <4AB4B60E.8050800@pi.nu> Date: Sat, 19 Sep 2009 12:44:30 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" Content-Type: multipart/mixed; boundary="------------080203070604050803030307" Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org Subject: [CCAMP] publication requested for draft-ietf-mpls-tp-nm-req-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: Sat, 19 Sep 2009 10:43:41 -0000 This is a multi-part message in MIME format. --------------080203070604050803030307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, We requested publication of draft-ietf-mpls-tp-nm-req-05.txt as an RFC on te standards track. The shepherd write-up is included. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 --------------080203070604050803030307 Content-Type: text/plain; name="mpls-tp-nm-req-A.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="mpls-tp-nm-req-A.txt" VGhlIE1QTFMgV0cgcmVxdWVzdHMgdGhhdDoNCiAgIE1QTFMgVFAgTmV0d29yayBNYW5hZ2Vt ZW50IFJlcXVpcmVtZW50cw0KICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1tcGxzLXRwLW5tLXJlcS0wNA0KaXMgcHVibGlzaGVkIGFzIGFuIFJGQyBvbiB0aGUg c3RhbmRhcmRzIHRyYWNrLg0KDQpOb3RlIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBhIHJlcXVp cmVtZW50IGRvY3VtZW50LiBGb3IgcmVhc29ucyB0aGF0DQpoYXZlIHRvIGRvIHdpdGggaG93 IHRoZSBJVFUtVCBjYW4gcmVmZXJlbmNlIFJGQ3Mgd2UgaGF2ZSBvcHRlZCB0byBwdXQNCml0 IG9uIHRoZSBTdGFuZGFyZHMgVHJhY2suDQoNCj4gKDEuYSkgV2hvIGlzIHRoZSBEb2N1bWVu dCBTaGVwaGVyZCBmb3IgdGhpcyBkb2N1bWVudD8gSGFzIHRoZQ0KPiAgICAgICBEb2N1bWVu dCBTaGVwaGVyZCBwZXJzb25hbGx5IHJldmlld2VkIHRoaXMgdmVyc2lvbiBvZiB0aGUNCj4g ICAgICAgZG9jdW1lbnQgYW5kLCBpbiBwYXJ0aWN1bGFyLCBkb2VzIGhlIG9yIHNoZSBiZWxp ZXZlIHRoaXMNCj4gICAgICAgdmVyc2lvbiBpcyByZWFkeSBmb3IgZm9yd2FyZGluZyB0byB0 aGUgSUVTRyBmb3IgcHVibGljYXRpb24/DQoNCkxvYSBBbmRlcnNzb24gaXMgdGhlIERvY3Vt ZW50IFNoZXBoZXJkLg0KSGUgaGFzIHJldmlld2VkIHRoZSBjb2R1bWVudCBhbmQgYmVsaWV2 ZXMgaXQgaXMgcmVhZHkgdG8gYmUNCmZvcndhcmRlZCB0byB0aGUgSUVTRyBmb3IgcHVibGlj YXRpb24uDQoNCj4gKDEuYikgSGFzIHRoZSBkb2N1bWVudCBoYWQgYWRlcXVhdGUgcmV2aWV3 IGJvdGggZnJvbSBrZXkgV0cgbWVtYmVycw0KPiAgICAgICBhbmQgZnJvbSBrZXkgbm9uLVdH IG1lbWJlcnM/IERvZXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhdmUNCj4gICAgICAgYW55 IGNvbmNlcm5zIGFib3V0IHRoZSBkZXB0aCBvciBicmVhZHRoIG9mIHRoZSByZXZpZXdzIHRo YXQNCj4gICAgICAgaGF2ZSBiZWVuIHBlcmZvcm1lZD8NCg0KVGhlIHJldmlldyBoYXMgYmVl biBzdWJzdGFudGlhbC4NCkNvbnNpZGVyYWJsZSBpbnB1dCB0byBlYXJseSByZXZpc2lvbnMg d2FzIHJlY2VpdmVkIGZyb20gTVBMUyBXRw0KcGFydGljaXBhbnRzIGFuZCBmcm9tIGEgZGV0 YWlsZWQgcmV2aWV3IGJ5IG1lbWJlcnMgb2YgSVRVLVQgU3R1ZHkNCkdyb3VwIDE1Lg0KDQpU aGUgV0cgbGFzdCBjYWxsIHdhcyBsaWFpc2VkIHRvIHRoZSBJVFUtVCBhbmQgcmVjZWl2ZWQg YSBudW1iZXIgb2YNCmNvbW1lbnRzIHRoYXQgd2VyZSBhZGRyZXNzZWQgaW4gdGhlIGZpbmFs IHJldmlzaW9uIHRoYXQgd2FzIGFwcHJvdmVkDQpieSB0aGUgSVRVLVQgaW4gYSBsaWFpc29u Lg0KDQpUaGUgV0cgbGFzdCBjYWxsIHdhcyBub3RpZmllZCB0byB0aGUgUFdFMyBhbmQgQ0NB TVAgd29ya2luZyBncm91cHMuDQoNCj4gKDEuYykgRG9lcyB0aGUgRG9jdW1lbnQgU2hlcGhl cmQgaGF2ZSBjb25jZXJucyB0aGF0IHRoZSBkb2N1bWVudA0KPiAgICAgICBuZWVkcyBtb3Jl IHJldmlldyBmcm9tIGEgcGFydGljdWxhciBvciBicm9hZGVyIHBlcnNwZWN0aXZlLA0KPiAg ICAgICBlLmcuLCBzZWN1cml0eSwgb3BlcmF0aW9uYWwgY29tcGxleGl0eSwgc29tZW9uZSBm YW1pbGlhciB3aXRoDQo+ICAgICAgIEFBQSwgaW50ZXJuYXRpb25hbGl6YXRpb24gb3IgWE1M Pw0KDQpOby4gVGhlIGRvY3VtZW50IGluY2x1ZGVzIGRldGFpbHMgb2YgbmV0d29yayBtYW5h Z2VtZW50IGZlYXR1cmVzLCBidXQNCndhcyBhdXRob3JlZCBhbmQgcmV2aWV3ZWQgYnkgbWFu eSBwZW9wbGUgYWN0aXZlIGluIHRoZSBPcGVyYXRpb25zIEFyZWEuDQoNCj4gKDEuZCkgRG9l cyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGF2ZSBhbnkgc3BlY2lmaWMgY29uY2VybnMgb3IN Cj4gICAgICAgaXNzdWVzIHdpdGggdGhpcyBkb2N1bWVudCB0aGF0IHRoZSBSZXNwb25zaWJs ZSBBcmVhIERpcmVjdG9yDQo+ICAgICAgIGFuZC9vciB0aGUgSUVTRyBzaG91bGQgYmUgYXdh cmUgb2Y/IEZvciBleGFtcGxlLCBwZXJoYXBzIGhlDQo+ICAgICAgIG9yIHNoZSBpcyB1bmNv bWZvcnRhYmxlIHdpdGggY2VydGFpbiBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQsIG9yDQo+ICAg ICAgIGhhcyBjb25jZXJucyB3aGV0aGVyIHRoZXJlIHJlYWxseSBpcyBhIG5lZWQgZm9yIGl0 LiBJbiBhbnkNCj4gICAgICAgZXZlbnQsIGlmIHRoZSBXRyBoYXMgZGlzY3Vzc2VkIHRob3Nl IGlzc3VlcyBhbmQgaGFzIGluZGljYXRlZA0KPiAgICAgICB0aGF0IGl0IHN0aWxsIHdpc2hl cyB0byBhZHZhbmNlIHRoZSBkb2N1bWVudCwgZGV0YWlsIHRob3NlDQo+ICAgICAgIGNvbmNl cm5zIGhlcmUuIEhhcyBhbiBJUFIgZGlzY2xvc3VyZSByZWxhdGVkIHRvIHRoaXMgZG9jdW1l bnQNCj4gICAgICAgYmVlbiBmaWxlZD8gSWYgc28sIHBsZWFzZSBpbmNsdWRlIGEgcmVmZXJl bmNlIHRvIHRoZQ0KPiAgICAgICBkaXNjbG9zdXJlIGFuZCBzdW1tYXJpemUgdGhlIFdHIGRp c2N1c3Npb24gYW5kIGNvbmNsdXNpb24gb24NCj4gICAgICAgdGhpcyBpc3N1ZS4NCg0KT25l IG9mZi1saW5lIGNvbW1lbnQgdGhhdCBoYXMgYmVlbiBmb3J3YXJkZWQgdG8gdGhlIHNoZXBo ZXJkIGlzIHRoYXQNCnRoZSBzdHlsZSBvZiB0aGUgZG9jdW1lbnQgaXMgdG9vIG11Y2ggb2Yg YW4gSVRVLVQgZG9jdW1lbnQuIFRoaXMNCmNvbW1lbnQgd2FzIG5vdCByYWlzZWQgb24gdGhl IGxpc3QgYW5kIHNlZW1zIG1vcmUgcmVsYXRlZCB0byB0aGUgZmFjdA0KdGhhdCB0aGUgSUVU RiBpcyBub3QgZmFtaWxpYXIgd2l0aCByZXF1aXJlbWVudHMgZG9jdW1lbnRzIHRoYW4gYmFz ZWQNCmluIGFueSBzcGVjaWZpYyBvYmplY3Rpb25zLg0KDQo+ICgxLmUpIEhvdyBzb2xpZCBp cyB0aGUgV0cgY29uc2Vuc3VzIGJlaGluZCB0aGlzIGRvY3VtZW50PyBEb2VzIGl0DQo+ICAg ICAgIHJlcHJlc2VudCB0aGUgc3Ryb25nIGNvbmN1cnJlbmNlIG9mIGEgZmV3IGluZGl2aWR1 YWxzLCB3aXRoDQo+ICAgICAgIG90aGVycyBiZWluZyBzaWxlbnQsIG9yIGRvZXMgdGhlIFdH IGFzIGEgd2hvbGUgdW5kZXJzdGFuZCBhbmQNCj4gICAgICAgYWdyZWUgd2l0aCBpdD8NCg0K RGV2ZWxvcG1lbnQgb2YgdGhlIGRvY3VtZW50IHdhcyBwZXJmb3JtZWQgd2l0aGluIHRoZSBN UExTLVRQIGRlc2lnbg0KdGVhbSAoYy4gMjAgcGVvcGxlKSB0aGF0IHN0cm9uZ2x5IHN1cHBv cnRzIHRoZSB3b3JrLiBUaGVyZSBoYXMgYWxzbw0KYmVlbiBzb21lIGRpc2N1c3Npb24gb24g dGhlIE1QTFMtVFAgKG9wZW4pIG1haWxpbmcgbGlzdCwgYW5kIHRoZXJlDQp3ZXJlIG5vIG9i amVjdGlvbnMgcmFpc2VkLg0KDQo+ICgxLmYpIEhhcyBhbnlvbmUgdGhyZWF0ZW5lZCBhbiBh cHBlYWwgb3Igb3RoZXJ3aXNlIGluZGljYXRlZCBleHRyZW1lDQo+ICAgICAgIGRpc2NvbnRl bnQ/IElmIHNvLCBwbGVhc2Ugc3VtbWFyaXNlIHRoZSBhcmVhcyBvZiBjb25mbGljdCBpbg0K PiAgICAgICBzZXBhcmF0ZSBlbWFpbCBtZXNzYWdlcyB0byB0aGUgUmVzcG9uc2libGUgQXJl YSBEaXJlY3Rvci4gKEl0DQo+ICAgICAgIHNob3VsZCBiZSBpbiBhIHNlcGFyYXRlIGVtYWls IGJlY2F1c2UgdGhpcyBxdWVzdGlvbm5haXJlIGlzDQo+ICAgICAgIGVudGVyZWQgaW50byB0 aGUgSUQgVHJhY2tlci4pDQoNCk5vIHRocmVhdHMgb3IgZXh0cmVtZSBkaXNjb250ZW50Lg0K DQo+ICgxLmcpIEhhcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgcGVyc29uYWxseSB2ZXJpZmll ZCB0aGF0IHRoZQ0KPiAgICAgICBkb2N1bWVudCBzYXRpc2ZpZXMgYWxsIElEIG5pdHM/IChT ZWUgdGhlIEludGVybmV0LURyYWZ0cyBDaGVja2xpc3QNCj4gICAgICAgYW5kIGh0dHA6Ly90 b29scy5pZXRmLm9yZy90b29scy9pZG5pdHMvKS4gQm9pbGVycGxhdGUgY2hlY2tzIGFyZQ0K PiAgICAgICBub3QgZW5vdWdoOyB0aGlzIGNoZWNrIG5lZWRzIHRvIGJlIHRob3JvdWdoLiBI YXMgdGhlIGRvY3VtZW50DQo+ICAgICAgIG1ldCBhbGwgZm9ybWFsIHJldmlldyBjcml0ZXJp YSBpdCBuZWVkcyB0bywgc3VjaCBhcyB0aGUgTUlCDQo+ICAgICAgIERvY3RvciwgbWVkaWEg dHlwZSBhbmQgVVJJIHR5cGUgcmV2aWV3cz8NCg0KQWxsIGNoZWNrcyBhcmUgY2xlYW4uDQoN Cj4gKDEuaCkgSGFzIHRoZSBkb2N1bWVudCBzcGxpdCBpdHMgcmVmZXJlbmNlcyBpbnRvIG5v cm1hdGl2ZSBhbmQNCj4gICAgICAgaW5mb3JtYXRpdmU/IEFyZSB0aGVyZSBub3JtYXRpdmUg cmVmZXJlbmNlcyB0byBkb2N1bWVudHMgdGhhdA0KPiAgICAgICBhcmUgbm90IHJlYWR5IGZv ciBhZHZhbmNlbWVudCBvciBhcmUgb3RoZXJ3aXNlIGluIGFuIHVuY2xlYXINCj4gICAgICAg c3RhdGU/IElmIHN1Y2ggbm9ybWF0aXZlIHJlZmVyZW5jZXMgZXhpc3QsIHdoYXQgaXMgdGhl DQo+ICAgICAgIHN0cmF0ZWd5IGZvciB0aGVpciBjb21wbGV0aW9uPyBBcmUgdGhlcmUgbm9y bWF0aXZlIHJlZmVyZW5jZXMNCj4gICAgICAgdGhhdCBhcmUgZG93bndhcmQgcmVmZXJlbmNl cywgYXMgZGVzY3JpYmVkIGluIFtSRkMzOTY3XT8gSWYNCj4gICAgICAgc28sIGxpc3QgdGhl c2UgZG93bndhcmQgcmVmZXJlbmNlcyB0byBzdXBwb3J0IHRoZSBBcmVhDQo+ICAgICAgIERp cmVjdG9yIGluIHRoZSBMYXN0IENhbGwgcHJvY2VkdXJlIGZvciB0aGVtIFtSRkMzOTY3XS4N Cg0KUmVmZXJlbmNlcyBhcmUgY29ycmVjdGx5IHNwbGl0Lg0KDQpUaGVyZSBhcmUgdHdvIG5v cm1hdGl2ZSByZWZlcmVuY2VzIHRvIEktRHMuDQoNCmRyYWZ0LWlldGYtbXBscy10cC1vYW0t cmVxdWlyZW1lbnRzIGhhcyBjb21wbGV0ZWQgV0cgbGFzdCBjYWxsIGFuZCB3aWxsDQpiZSBy ZWFkeSBmb3IgYWR2YW5jZW1lbnQgc29vbi4NCg0KZHJhZnQtaWV0Zi1tcGxzLXRwLXJlcXVp cmVtZW50cyBpcyBvbiB0aGUgUkZDIEVkaXRvcidzIFF1ZXVlLg0KDQpUaGVyZSBhcmUgdHdv IGRvd25yZWZzLiBUaGVzZSBhcmUgZGVsaWJlcmF0ZS4NCg0KUkZDIDQzNzcgT3BlcmF0aW9u cyBhbmQgTWFuYWdlbWVudCAoT0FNKSBSZXF1aXJlbWVudHMgZm9yIE11bHRpLVByb3RvY29s DQogICAgICAgICBMYWJlbCBTd2l0Y2hlZCAoTVBMUykgTmV0d29ya3MNCg0KUkZDIDM4NzEg T3BlcmF0aW9uYWwgU2VjdXJpdHkgUmVxdWlyZW1lbnRzIGZvciBMYXJnZSBJbnRlcm5ldCBT ZXJ2aWNlDQogICAgICAgICBQcm92aWRlciAoSVNQKSBJUCBOZXR3b3JrIEluZnJhc3RydWN0 dXJlDQoNClJlZmVyZW5jZXMgdG8gSW5mb3JtYXRpb25hbCBSRkMncyA0Mzc3IGFuZCAzODcx IGhhdmUgdG8gYmUgbWFkZSBleHBsaWNpdA0KaW4gdGhlIElFVEYgbGFzdCBjYWxsLg0KDQo+ ICgxLmkpIEhhcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgdmVyaWZpZWQgdGhhdCB0aGUgZG9j dW1lbnQgSUFOQQ0KPiAgICAgICBjb25zaWRlcmF0aW9uIHNlY3Rpb24gZXhpc3RzIGFuZCBp cyBjb25zaXN0ZW50IHdpdGggdGhlIGJvZHkNCj4gICAgICAgb2YgdGhlIGRvY3VtZW50PyBJ ZiB0aGUgZG9jdW1lbnQgc3BlY2lmaWVzIHByb3RvY29sDQo+ICAgICAgIGV4dGVuc2lvbnMs IGFyZSByZXNlcnZhdGlvbnMgcmVxdWVzdGVkIGluIGFwcHJvcHJpYXRlIElBTkENCj4gICAg ICAgcmVnaXN0cmllcz8gQXJlIHRoZSBJQU5BIHJlZ2lzdHJpZXMgY2xlYXJseSBpZGVudGlm aWVkPyBJZg0KPiAgICAgICB0aGUgZG9jdW1lbnQgY3JlYXRlcyBhIG5ldyByZWdpc3RyeSwg ZG9lcyBpdCBkZWZpbmUgdGhlDQo+ICAgICAgIHByb3Bvc2VkIGluaXRpYWwgY29udGVudHMg b2YgdGhlIHJlZ2lzdHJ5IGFuZCBhbiBhbGxvY2F0aW9uDQo+ICAgICAgIHByb2NlZHVyZSBm b3IgZnV0dXJlIHJlZ2lzdHJhdGlvbnM/IERvZXMgaXQgc3VnZ2VzdCBhDQo+ICAgICAgIHJl YXNvbmFibGUgbmFtZSBmb3IgdGhlIG5ldyByZWdpc3RyeT8gU2VlIFtSRkM1MjI2XS4gSWYg dGhlDQo+ICAgICAgIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBFeHBlcnQgUmV2aWV3IHByb2Nl c3MgaGFzIFNoZXBoZXJkDQo+ICAgICAgIGNvbmZlcnJlZCB3aXRoIHRoZSBSZXNwb25zaWJs ZSBBcmVhIERpcmVjdG9yIHNvIHRoYXQgdGhlIElFU0cNCj4gICAgICAgY2FuIGFwcG9pbnQg dGhlIG5lZWRlZCBFeHBlcnQgZHVyaW5nIHRoZSBJRVNHIEV2YWx1YXRpb24/DQoNClRoZXJl IGFyZSBubyBJQU5BIGFjdGlvbnMgYXNzb2NpYXRlZCB3aXRoIHRoaXMgZG9jdW1lbnQuDQoN CkEgbnVsbCBJQU5BIHNlY3Rpb24gaXMgcHJlc2VudC4NCg0KDQo+ICgxLmopIEhhcyB0aGUg RG9jdW1lbnQgU2hlcGhlcmQgdmVyaWZpZWQgdGhhdCBzZWN0aW9ucyBvZiB0aGUNCj4gICAg ICAgZG9jdW1lbnQgdGhhdCBhcmUgd3JpdHRlbiBpbiBhIGZvcm1hbCBsYW5ndWFnZSwgc3Vj aCBhcyBYTUwNCj4gICAgICAgY29kZSwgQk5GIHJ1bGVzLCBNSUIgZGVmaW5pdGlvbnMsIGV0 Yy4sIHZhbGlkYXRlIGNvcnJlY3RseSBpbg0KPiAgICAgICBhbiBhdXRvbWF0ZWQgY2hlY2tl cj8NCg0KTm8gc3VjaCBmb3JtYWwgbGFuZ3VhZ2UuDQoNCj4gKDEuaykgVGhlIElFU0cgYXBw cm92YWwgYW5ub3VuY2VtZW50IGluY2x1ZGVzIGEgRG9jdW1lbnQNCj4gICAgICAgQW5ub3Vu Y2VtZW50IFdyaXRlLVVwLiBQbGVhc2UgcHJvdmlkZSBzdWNoIGEgRG9jdW1lbnQNCj4gICAg ICAgQW5ub3VuY2VtZW50IFdyaXRlLVVwPyBSZWNlbnQgZXhhbXBsZXMgY2FuIGJlIGZvdW5k IGluIHRoZQ0KPiAgICAgICAiQWN0aW9uIiBhbm5vdW5jZW1lbnRzIGZvciBhcHByb3ZlZCBk b2N1bWVudHMuIFRoZSBhcHByb3ZhbA0KPiAgICAgICBhbm5vdW5jZW1lbnQgY29udGFpbnMg dGhlIGZvbGxvd2luZyBzZWN0aW9uczoNCg0KVGVjaG5pY2FsIFN1bW1hcnkNCg0KICBUaGlz IGRvY3VtZW50IHNwZWNpZmllcyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgbWFuYWdlbWVu dCBvZg0KICBlcXVpcG1lbnQgdXNlZCBpbiBuZXR3b3JrcyBzdXBwb3J0aW5nIGFuIE1QTFMg VHJhbnNwb3J0IFByb2ZpbGUNCiAgKE1QTFMtVFApLiBUaGUgcmVxdWlyZW1lbnRzIGFyZSBk ZWZpbmVkIGZvciBzcGVjaWZpY2F0aW9uIG9mDQogIG5ldHdvcmsgbWFuYWdlbWVudCBhc3Bl Y3RzIG9mIHByb3RvY29sIG1lY2hhbmlzbXMgYW5kIHByb2NlZHVyZXMNCiAgdGhhdCBjb25z dGl0dXRlIHRoZSBidWlsZGluZyBibG9ja3Mgb3V0IG9mIHdoaWNoIHRoZSBNUExTDQogIHRy YW5zcG9ydCBwcm9maWxlIGlzIGNvbnN0cnVjdGVkLiAgVGhhdCBpcywgdGhlc2UgcmVxdWly ZW1lbnRzDQogIGluZGljYXRlIHdoYXQgbWFuYWdlbWVudCBjYXBhYmlsaXRpZXMgbmVlZCB0 byBiZSBhdmFpbGFibGUgaW4NCiAgTVBMUyBmb3IgdXNlIGluIG1hbmFnaW5nIHRoZSBNUExT LVRQLiBUaGlzIGRvY3VtZW50IGlzIGludGVuZGVkDQogIHRvIGlkZW50aWZ5IGVzc2VudGlh bCBuZXR3b3JrIG1hbmFnZW1lbnQgY2FwYWJpbGl0aWVzLCBub3QgdG8NCiAgc3BlY2lmeSB3 aGF0IGZ1bmN0aW9ucyBhbnkgcGFydGljdWxhciBNUExTIGltcGxlbWVudGF0aW9uDQogIHN1 cHBvcnRzLg0KDQoNCldvcmtpbmcgR3JvdXAgU3VtbWFyeQ0KDQogIFRoZSBkb2N1bWVudCBp cyBwYXJ0IG9mIHRoZSBNUExTLVRQIHByb2plY3QsIHRoZSBjb29wZXJhdGlvbg0KICBiZXR3 ZWVuIElFVEYgYW5kIElUVS1UIHRvIHNwZWNpZnkgYW4gTVBMUyB0cmFuc3BvcnQgcHJvZmls ZS4NCiAgVGhlcmUgYXJlIG5vIG91dHN0YW5kaW5nIGlzc3Vlcy4gSXQgaXMgcHV0IG9uIHRo ZSBzdGFuZGFyZHMNCiAgdHJhY2sgdG8gcmVzb2x2ZSBpc3N1ZXMgYXJvdW5kIGhvdyB0aGUg SVRVLVQgcmVmZXJlbmNlcyBJRVRGDQogIGRvY3VtZW50cy4NCg0KRG9jdW1lbnQgUXVhbGl0 eQ0KDQogIFRoZSBkb2N1bWVudCBpcyBhIHJlcXVpcmVtZW50cyBzcGVjaWZpY2F0aW9uIGFu ZCB3aWxsIG1haW5seQ0KICBiZSB1c2VkIGFzIGlucHV0IHRvIHRoZSBuZXR3b3JrIG1hbmFn ZW1lbnQgc29sdXRpb25zIHNwZWNpZmljYXRpb25zDQogIHRoYXQgd2lsbCBiZSBwdWJsaXNo ZWQgc2hvcnRseS4= --------------080203070604050803030307-- From sunwq@MIT.EDU Sun Sep 20 19:17:38 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45723A68A5 for ; Sun, 20 Sep 2009 19:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.761 X-Spam-Level: X-Spam-Status: No, score=-5.761 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lY-DidjNK7mr for ; Sun, 20 Sep 2009 19:17:37 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id B60983A68AC for ; Sun, 20 Sep 2009 19:17:37 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n8L2IXtQ003093; Sun, 20 Sep 2009 22:18:35 -0400 (EDT) Received: from APC ([202.120.39.240]) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n8L2IRHJ012143 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 20 Sep 2009 22:18:30 -0400 (EDT) Message-ID: <51C8D50095CF4C54BFC893B471C3406F@mit.edu> From: "Weiqiang Sun" To: "Lou Berger" References: <4AA6C495.4080306@labn.net><4AAACA4E.3040006@labn.net><4AAFF757.4060102@labn.net><896C8760F85A43F2927F7BD0E284DC79@mit.edu><4AB21803.70201@labn.net> <4AB3E4D6.90807@labn.net> In-Reply-To: <4AB3E4D6.90807@labn.net> Date: Mon, 21 Sep 2009 10:18:28 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Cc: draft-ietf-ccamp-lsp-dppm@tools.ietf.org, ccamp@ietf.org Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm 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, 21 Sep 2009 02:17:38 -0000 Lou, This sounds great to me. Many thanks, Weiqiang -------------------------------------------------- From: "Lou Berger" Sent: Saturday, September 19, 2009 3:51 AM To: "Weiqiang Sun" Cc: ; Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm > Weiqiang, > How about something along the lines of : > > 14.x. The Maximum of Metric > > The maximum of metric is the maximum of all the dT values in the > sample. In computing this, undefined values MUST NOT be included. > Note that this means that measurements that exceed the upper bound > are not reported in this statistic. This is an important > consideration when evaluating the maximum when the number of > undefined measurements is non-zero. > > Lou > > On 9/17/2009 10:14 AM, Weiqiang Sun wrote: >> Hi Lou, >> >> I agree with you on 1. >> As for 2, what I can come up with is the text below. I can not persuade >> myself to put it in the draft :(. Maybe you have better ways of putting >> it... >> >> 14.x. The Maximum of Metric >> >> The maximum of metric is the maximum of all the dT values in the >> sample. In computing this, undefined values MUST NOT be counted in. >> Note that this means that the maximum could thus be undefined if all >> the dT values are undefined. In addition, the metric maximum SHOULD >> be set to undefined if the sample is empty. >> >> It also must be noted that exceptionally a measurement may result in a >> value that is greater than the upper bound and is thus deemed >> undefined. >> Because of this, the maximum of metric must be used with caution. >> >> Thanks, >> Weiqiang >> >> -------------------------------------------------- >> From: "Lou Berger" >> Sent: Thursday, September 17, 2009 7:05 PM >> To: "Weiqiang Sun" >> Cc: ; >> Subject: Re: [CCAMP] 2nd Working group last call: >> draft-ietf-ccamp-lsp-dppm >> >>> Weiqiang, >>> It seems we're left with two open topics: >>> >>> 1) I propose addressing the total count topic using text along the >>> lines of: >>> >>> (section 4-8): >>> o All collected metrics together with the total number of values >>> (both real and undefined) and the selected upper bound MUST be >>> reported. >>> >>> Section 9, 10, 11,12 ,13 : >>> >>> o All collected metrics together with the total number of values >>> (both real and undefined) and the selected parameters MUST be >>> reported. >>> >>> 2) >>> >>>>>>> Is there a reason that you included Minimum and Median in >>>>>>> Section 14, but not maximum? >>>>>> Minimum and Median values are generally more stable than maximum in a >>>>>> large >>>>>> measurement and can provide valuable sights to the DUT/SUT. >>>>> >>>>> Sure, but maximums provide an important view into what can be expected >>>>> from the system. Without the max value there is no way to understand >>>>> worst case behavior. I think it's worth including. >>>> Yes it may be helpful, but it might also be dangerous to say the >>>> maximum >>>> reflects the worst case behavior, when all reported values are bounded >>>> (by a preset upper bound). >>>> In this sense the ``maximum" by its name may be misleading... >>>> >>> >>> Well this depends on the selected upper bound. Also, yes statistics >>> *can* be misread, but if the data isn't present there's no way for the >>> results to be properly interpreted. >>> >>> Lou >>> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From wwwrun@core3.amsl.com Mon Sep 21 07:30:50 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 51B983A6AA9; Mon, 21 Sep 2009 07:30:50 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090921143050.51B983A6AA9@core3.amsl.com> Date: Mon, 21 Sep 2009 07:30:50 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] Last Call: draft-ietf-ccamp-mpls-graceful-shutdown (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 Reply-To: ietf@ietf.org List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 14:30:50 -0000 The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-10-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-mpls-graceful-shutdown-12.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15135&rfc_flag=0 From jonas.martensson@acreo.se Mon Sep 21 08:20:14 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 592A728C0E4 for ; Mon, 21 Sep 2009 08:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.616 X-Spam-Level: X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_20=-0.74, HELO_EQ_DK=1.009, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-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 W7uD1xHqkTxb for ; Mon, 21 Sep 2009 08:20:13 -0700 (PDT) Received: from deframx18.softcom.dk (deframx18.softcom.dk [80.237.202.18]) by core3.amsl.com (Postfix) with ESMTP id CAFDD3A6782 for ; Mon, 21 Sep 2009 08:20:12 -0700 (PDT) Received: (qmail 18817 invoked by uid 74); 21 Sep 2009 15:21:12 -0000 Received: from mail.acreo.se (217.151.195.216) by deframx18.softcom.dk (envelope-from ) with ESMTP. tag msg.1253546472.160507.22067 (Processed in 0.300124 secs); 21 Sep 2009 15:21:12 -0000 X-SoftScan-Status: clean X-Secure-TLS: Yes, message received through TLS by deframx18.softcom.dk (RC4-MD5) Received: from mail.acreo.se (HELO mail.acreo.se) (217.151.195.216) by deframx18.softcom.dk over TLS secured channel with (RC4-MD5 encrypted) ESMTPS; Mon, 21 Sep 2009 17:21:12 +0200 Received: from acreoexc01.ad.acreo.se ([10.4.148.12]) by acreoexc01.ad.acreo.se ([10.4.148.12]) with mapi; Mon, 21 Sep 2009 17:21:11 +0200 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: Young Lee , 'Giovanni Martinelli' Date: Mon, 21 Sep 2009 17:21:11 +0200 Thread-Topic: [CCAMP] rwa wson framework: multi-degree ROADM Thread-Index: Aco3bMx5EppOp3ktSsuUZkv1e2TdoQBKLuygAI14j+A= Message-ID: <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BA4@acreoexc01.ad.acreo.se> References: <4AAFB210.8000802@cisco.com> <4AAFB6FF.2060301@grotto-networking.com> <4AB1EC48.2050407@cisco.com> <002001ca389a$1e7eb5a0$4c0c7c0a@china.huawei.com> In-Reply-To: <002001ca389a$1e7eb5a0$4c0c7c0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM 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, 21 Sep 2009 15:20:14 -0000 Hi Young, Actually, I think the figure you propose is a bit confusing for a couple of= reasons: 1) It only depicts either ingress or egress for the four directions while i= n practice links are typically bidirectional. (The same is true for the deg= ree-2 ROADM example in the draft but there it is less confusing.) 2) The way the ports are numbered, to me it looks like Ingress 1(2) and Egr= ess 1(2) are associated to the same direction which means that to me it loo= ks more like a degree-2 ROADM. I think it would be clearer if you made all ports in the figures bidirectio= nal. Regards, Jonas > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 > On Behalf Of Young Lee > Sent: den 18 september 2009 21:57 > To: 'Giovanni Martinelli' > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >=20 > Hi Giovanni,=20 >=20 > We have added 4-degree ROADM figure and connectivity matrix=20 > per your suggestion in the draft. Below is tentative text we=20 > have added in Section 3.3.1. I hope this would satisfy your request.=20 >=20 > Thanks.=20 >=20 > Young > ---------------------------------------------------------------- >=20 > Ingress 1 +---------------+ +---------------+ Egress 1=20 > =20 > ----> | | -->| |---->=20 > Ingress 2 | | | | Egress 2 > ----> | | -->| |---->=20 > +---------------+ +---------------+ > | | | | | | O O O O O O > | | | | | | | | | | | | > O O O O O O | | | | | | > E3 E4 E5 E6 E7 E8 I3 I4 I5 I6 I7 I8 > =20 > Triburary Side Drop Add=20 >=20 > Figure 2 Degree-4 ROADM >=20 > For the ROADM of Figure 2 the switched connectivity matrix=20 > can be expressed as follows. Note that this ROADM is based on=20 > per port add/drop.=20 >=20 > Ingress Egress Port > Port #1 #2 #3 #4 #5 #6 #7 #8 > -------------- > #1: 1 1 0 0 0 1 1 1 > #2 1 1 1 1 1 0 0 0 > A =3D #3 0 1 0 0 0 0 0 0 > #4 0 1 0 0 0 0 0 0 > #5 0 1 0 0 0 0 0 0 > #6 1 0 0 0 0 0 0 0=20 > #7 1 0 0 0 0 0 0 0=20 > #8 1 0 0 0 0 0 0 0 > =20 >=20 > Where egress ports 3-5 are drop ports from Ingress 2 and=20 > egress ports 6-8 are drop ports from Ingress 1 and ingress=20 > ports 3-5 are add ports to Egress 2, ingress ports 6-8 are=20 > add ports to Egress 1. >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 > On Behalf Of Giovanni Martinelli > Sent: Thursday, September 17, 2009 2:59 AM > To: Greg Bernstein > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >=20 > Hi Greg, >=20 > Greg Bernstein wrote: > > Hi Giovanni, in the example given in section 5 (thanks to Dirk) we=20 > > have multi-degree ROADMs. In section 3.3.1 we do mention=20 > higher degree=20 > > ROADMs but refer readers to another draft. Hmm, maybe we=20 > should also=20 > > point them to section 5. >=20 > um well Section 5 provide more a high level overview and the=20 > scope is a bit different while the other reference at the end=20 > still contain 2 degree roadm (unless I'm missing something) >=20 > This section was providing details about how a roadm is=20 > presented and the respective connectivity matrix (while in=20 > other examples the connectivity matrix only shows what is=20 > important for the example itself). >=20 > To me this is important to show how exactly every roadm can=20 > be represented (and I guess generalizing from 4 to n will be=20 > clearer than doing from 2 to n degree) and the size of the=20 > matrix (then how is sparse is another topic). >=20 >=20 > > While I don't mind adding another picture, I think the=20 > chairs will be=20 > > more interested in us reducing the length of the document than=20 > > expanding it ;-) . > > > well hope it's not the main criteria (we can always shot for=20 > the longest > RFC) ;-) >=20 > Cheers > G >=20 > > Cheers > > > > Greg > > > > Giovanni Martinelli wrote: > >> Hi Greg & WSONers, > >> > >> well, I saw you just suggest a last call request but I was=20 > wondering=20 > >> about representing a more general case of ROAM in section 3.3.1 > >> > >> The ID currently represent a 2 degree ROADM but looks to me a very=20 > >> specific case so I'm asking if it's ok adding a 4 degree=20 > ROADM as well. > >> > >> > >> Here just a rough idea starting from your current picture > >> > >> +---------------------+ Line=20 > side-1 ingress > >> --->| |---> Line side-2 egress > >> Line side-1 egress <---| |<--- Line side-2=20 > >> ingress > >> | ROADM | > >> Line side-3 ingress --->| |---> Line=20 > side-4 egress > >> Line side-3 egress <---| |<--- Line side-4=20 > >> ingress > >> | | > >> +---------------------+ > >> | | | | o o o o > >> | | | | | | | | > >> O O O O | | | | > >> Tributary Side: Drop (egress) Add (ingress) > >> > >> > >> 1/ line sides likely have ingress and egress. > >> > >> > >> 2/ Tributaries might be associated to sides but I would=20 > consider that=20 > >> as switching constrain. > >> > >> Does the switching matrix will apply in the same way,=20 > become an 8x8=20 > >> right?. > >> > >> Any thoughts about? > >> > >> > >> Cheers > >> G > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > >> > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 > = From ylee@huawei.com Mon Sep 21 08:56:12 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39683A6A7A for ; Mon, 21 Sep 2009 08:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=-1.202, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] 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 czWkBz3QBI24 for ; Mon, 21 Sep 2009 08:56:11 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id BEC383A6870 for ; Mon, 21 Sep 2009 08:56:11 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQB000UMWBB7M@usaga02-in.huawei.com> for ccamp@ietf.org; Mon, 21 Sep 2009 08:57:12 -0700 (PDT) Received: from L73682 ([10.124.12.76]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQB008Y1WB058@usaga02-in.huawei.com> for ccamp@ietf.org; Mon, 21 Sep 2009 08:57:11 -0700 (PDT) Date: Mon, 21 Sep 2009 10:57:00 -0500 From: Young Lee In-reply-to: <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BA4@acreoexc01.ad.acreo.se> To: =?iso-8859-1?Q?'Jonas_M=E5rtensson'?= , 'Giovanni Martinelli' Message-id: <001d01ca3ad4$2c1127c0$4c0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: Aco3bMx5EppOp3ktSsuUZkv1e2TdoQBKLuygAI14j+AAAdmVEA== References: <4AAFB210.8000802@cisco.com> <4AAFB6FF.2060301@grotto-networking.com> <4AB1EC48.2050407@cisco.com> <002001ca389a$1e7eb5a0$4c0c7c0a@china.huawei.com> <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BA4@acreoexc01.ad.acreo.se> Cc: ccamp@ietf.org Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM 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, 21 Sep 2009 15:56:12 -0000 Hi Jonas, Yes you are right. Due to the ASCII limitation, the figures for both 2-degree and 4-degree ROADM are shown only for one direction. For your question (2), we have added a note that this ROADM is based on per port add/drop (which is hard to show with ASCII) which means Ingress 1(2) and Egress 1(2) are associated to the different directions.=20 Hope this clarifies your question... Thanks.=20 Regards, Young -----Original Message----- From: Jonas M=E5rtensson [mailto:Jonas.Martensson@acreo.se]=20 Sent: Monday, September 21, 2009 10:21 AM To: Young Lee; 'Giovanni Martinelli' Cc: ccamp@ietf.org Subject: RE: [CCAMP] rwa wson framework: multi-degree ROADM Hi Young, Actually, I think the figure you propose is a bit confusing for a couple = of reasons: 1) It only depicts either ingress or egress for the four directions = while in practice links are typically bidirectional. (The same is true for the degree-2 ROADM example in the draft but there it is less confusing.) 2) The way the ports are numbered, to me it looks like Ingress 1(2) and Egress 1(2) are associated to the same direction which means that to me = it looks more like a degree-2 ROADM. I think it would be clearer if you made all ports in the figures bidirectional. Regards, Jonas > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 > On Behalf Of Young Lee > Sent: den 18 september 2009 21:57 > To: 'Giovanni Martinelli' > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >=20 > Hi Giovanni,=20 >=20 > We have added 4-degree ROADM figure and connectivity matrix=20 > per your suggestion in the draft. Below is tentative text we=20 > have added in Section 3.3.1. I hope this would satisfy your request.=20 >=20 > Thanks.=20 >=20 > Young > ---------------------------------------------------------------- >=20 > Ingress 1 +---------------+ +---------------+ Egress 1=20 > =20 > ----> | | -->| |---->=20 > Ingress 2 | | | | Egress 2 > ----> | | -->| |---->=20 > +---------------+ +---------------+ > | | | | | | O O O O O O > | | | | | | | | | | | | > O O O O O O | | | | | | > E3 E4 E5 E6 E7 E8 I3 I4 I5 I6 I7 I8 > =20 > Triburary Side Drop Add=20 >=20 > Figure 2 Degree-4 ROADM >=20 > For the ROADM of Figure 2 the switched connectivity matrix=20 > can be expressed as follows. Note that this ROADM is based on=20 > per port add/drop.=20 >=20 > Ingress Egress Port > Port #1 #2 #3 #4 #5 #6 #7 #8 > -------------- > #1: 1 1 0 0 0 1 1 1 > #2 1 1 1 1 1 0 0 0 > A =3D #3 0 1 0 0 0 0 0 0 > #4 0 1 0 0 0 0 0 0 > #5 0 1 0 0 0 0 0 0 > #6 1 0 0 0 0 0 0 0=20 > #7 1 0 0 0 0 0 0 0=20 > #8 1 0 0 0 0 0 0 0 > =20 >=20 > Where egress ports 3-5 are drop ports from Ingress 2 and=20 > egress ports 6-8 are drop ports from Ingress 1 and ingress=20 > ports 3-5 are add ports to Egress 2, ingress ports 6-8 are=20 > add ports to Egress 1. >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 > On Behalf Of Giovanni Martinelli > Sent: Thursday, September 17, 2009 2:59 AM > To: Greg Bernstein > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >=20 > Hi Greg, >=20 > Greg Bernstein wrote: > > Hi Giovanni, in the example given in section 5 (thanks to Dirk) we=20 > > have multi-degree ROADMs. In section 3.3.1 we do mention=20 > higher degree=20 > > ROADMs but refer readers to another draft. Hmm, maybe we=20 > should also=20 > > point them to section 5. >=20 > um well Section 5 provide more a high level overview and the=20 > scope is a bit different while the other reference at the end=20 > still contain 2 degree roadm (unless I'm missing something) >=20 > This section was providing details about how a roadm is=20 > presented and the respective connectivity matrix (while in=20 > other examples the connectivity matrix only shows what is=20 > important for the example itself). >=20 > To me this is important to show how exactly every roadm can=20 > be represented (and I guess generalizing from 4 to n will be=20 > clearer than doing from 2 to n degree) and the size of the=20 > matrix (then how is sparse is another topic). >=20 >=20 > > While I don't mind adding another picture, I think the=20 > chairs will be=20 > > more interested in us reducing the length of the document than=20 > > expanding it ;-) . > > > well hope it's not the main criteria (we can always shot for=20 > the longest > RFC) ;-) >=20 > Cheers > G >=20 > > Cheers > > > > Greg > > > > Giovanni Martinelli wrote: > >> Hi Greg & WSONers, > >> > >> well, I saw you just suggest a last call request but I was=20 > wondering=20 > >> about representing a more general case of ROAM in section 3.3.1 > >> > >> The ID currently represent a 2 degree ROADM but looks to me a very=20 > >> specific case so I'm asking if it's ok adding a 4 degree=20 > ROADM as well. > >> > >> > >> Here just a rough idea starting from your current picture > >> > >> +---------------------+ Line=20 > side-1 ingress > >> --->| |---> Line side-2 egress > >> Line side-1 egress <---| |<--- Line side-2=20 > >> ingress > >> | ROADM | > >> Line side-3 ingress --->| |---> Line=20 > side-4 egress > >> Line side-3 egress <---| |<--- Line side-4=20 > >> ingress > >> | | > >> +---------------------+ > >> | | | | o o o o > >> | | | | | | | | > >> O O O O | | | | > >> Tributary Side: Drop (egress) Add (ingress) > >> > >> > >> 1/ line sides likely have ingress and egress. > >> > >> > >> 2/ Tributaries might be associated to sides but I would=20 > consider that=20 > >> as switching constrain. > >> > >> Does the switching matrix will apply in the same way,=20 > become an 8x8=20 > >> right?. > >> > >> Any thoughts about? > >> > >> > >> Cheers > >> G > >> _______________________________________________ > >> CCAMP mailing list > >> CCAMP@ietf.org > >> https://www.ietf.org/mailman/listinfo/ccamp > >> > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 >=20 From giomarti@cisco.com Mon Sep 21 09:24:56 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088843A68B7 for ; Mon, 21 Sep 2009 09:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCcXSllZkJGK for ; Mon, 21 Sep 2009 09:24:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 479143A68EA for ; Mon, 21 Sep 2009 09:24:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsAADNGt0qQ/uCKe2dsb2JhbACadAEBFiQGn3iIUAGOQQWEGw X-IronPort-AV: E=Sophos;i="4.44,425,1249257600"; d="scan'208";a="49884159" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Sep 2009 16:25:54 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8LGPs1f006592; Mon, 21 Sep 2009 18:25:54 +0200 Received: from [144.254.166.108] (mnza1-dhcp-vl301-144-254-166-108.cisco.com [144.254.166.108]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8LGPrmv023388; Mon, 21 Sep 2009 16:25:54 GMT Message-ID: <4AB7A915.9000903@cisco.com> Date: Mon, 21 Sep 2009 18:25:57 +0200 From: Giovanni Martinelli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Young Lee References: <4AAFB210.8000802@cisco.com> <4AAFB6FF.2060301@grotto-networking.com> <4AB1EC48.2050407@cisco.com> <002001ca389a$1e7eb5a0$4c0c7c0a@china.huawei.com> <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BA4@acreoexc01.ad.acreo.se> <001d01ca3ad4$2c1127c0$4c0c7c0a@china.huawei.com> In-Reply-To: <001d01ca3ad4$2c1127c0$4c0c7c0a@china.huawei.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7758; t=1253550354; x=1254414354; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=giomarti@cisco.com; z=From:=20Giovanni=20Martinelli=20 |Subject:=20Re=3A=20[CCAMP]=20rwa=20wson=20framework=3A=20m ulti-degree=20ROADM |Sender:=20; bh=d8Op+H0/9c6PR91MA4nVvlXaUzeqB34WE5lvxVMdz+o=; b=mPs4Qw2qzDObwOVANS7lq69tH9vt8RETJ8MDoNakBlYones8sH9XtevLiZ GG3xvmUzBhLxRuw9U4gL+yo1x2eAcUml4cu+s8rAa7ondUF7Ss7oGfNzaLDf fHEfegmHGH; Authentication-Results: ams-dkim-1; header.From=giomarti@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ccamp@ietf.org Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM 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, 21 Sep 2009 16:24:56 -0000 Hi, Young Lee wrote: > Hi Jonas, > > Yes you are right. Due to the ASCII limitation, the figures for both > 2-degree and 4-degree ROADM are shown only for one direction. although ascii art difficult, I got the issue in understanding where bi-directionality apply as well. That's why I was trying to get all directions in one picture (but not sure the result was ok). > For your > question (2), we have added a note that this ROADM is based on per port > add/drop (which is hard to show with ASCII) which means Ingress 1(2) and > Egress 1(2) are associated to the different directions. > > One more clarification on the topic: the fact that we represent connectivity matrix done by (ingress x egress) it means we have a matrix for each directions? thx G > Hope this clarifies your question... Thanks. > > Regards, > Young > > -----Original Message----- > From: Jonas Mårtensson [mailto:Jonas.Martensson@acreo.se] > Sent: Monday, September 21, 2009 10:21 AM > To: Young Lee; 'Giovanni Martinelli' > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] rwa wson framework: multi-degree ROADM > > Hi Young, > > Actually, I think the figure you propose is a bit confusing for a couple of > reasons: > > 1) It only depicts either ingress or egress for the four directions while in > practice links are typically bidirectional. (The same is true for the > degree-2 ROADM example in the draft but there it is less confusing.) > > 2) The way the ports are numbered, to me it looks like Ingress 1(2) and > Egress 1(2) are associated to the same direction which means that to me it > looks more like a degree-2 ROADM. > > I think it would be clearer if you made all ports in the figures > bidirectional. > > Regards, > Jonas > > >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >> On Behalf Of Young Lee >> Sent: den 18 september 2009 21:57 >> To: 'Giovanni Martinelli' >> Cc: ccamp@ietf.org >> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >> >> Hi Giovanni, >> >> We have added 4-degree ROADM figure and connectivity matrix >> per your suggestion in the draft. Below is tentative text we >> have added in Section 3.3.1. I hope this would satisfy your request. >> >> Thanks. >> >> Young >> ---------------------------------------------------------------- >> >> Ingress 1 +---------------+ +---------------+ Egress 1 >> >> ----> | | -->| |----> >> Ingress 2 | | | | Egress 2 >> ----> | | -->| |----> >> +---------------+ +---------------+ >> | | | | | | O O O O O O >> | | | | | | | | | | | | >> O O O O O O | | | | | | >> E3 E4 E5 E6 E7 E8 I3 I4 I5 I6 I7 I8 >> >> Triburary Side Drop Add >> >> Figure 2 Degree-4 ROADM >> >> For the ROADM of Figure 2 the switched connectivity matrix >> can be expressed as follows. Note that this ROADM is based on >> per port add/drop. >> >> Ingress Egress Port >> Port #1 #2 #3 #4 #5 #6 #7 #8 >> -------------- >> #1: 1 1 0 0 0 1 1 1 >> #2 1 1 1 1 1 0 0 0 >> A = #3 0 1 0 0 0 0 0 0 >> #4 0 1 0 0 0 0 0 0 >> #5 0 1 0 0 0 0 0 0 >> #6 1 0 0 0 0 0 0 0 >> #7 1 0 0 0 0 0 0 0 >> #8 1 0 0 0 0 0 0 0 >> >> >> Where egress ports 3-5 are drop ports from Ingress 2 and >> egress ports 6-8 are drop ports from Ingress 1 and ingress >> ports 3-5 are add ports to Egress 2, ingress ports 6-8 are >> add ports to Egress 1. >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] >> On Behalf Of Giovanni Martinelli >> Sent: Thursday, September 17, 2009 2:59 AM >> To: Greg Bernstein >> Cc: ccamp@ietf.org >> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >> >> Hi Greg, >> >> Greg Bernstein wrote: >> >>> Hi Giovanni, in the example given in section 5 (thanks to Dirk) we >>> have multi-degree ROADMs. In section 3.3.1 we do mention >>> >> higher degree >> >>> ROADMs but refer readers to another draft. Hmm, maybe we >>> >> should also >> >>> point them to section 5. >>> >> um well Section 5 provide more a high level overview and the >> scope is a bit different while the other reference at the end >> still contain 2 degree roadm (unless I'm missing something) >> >> This section was providing details about how a roadm is >> presented and the respective connectivity matrix (while in >> other examples the connectivity matrix only shows what is >> important for the example itself). >> >> To me this is important to show how exactly every roadm can >> be represented (and I guess generalizing from 4 to n will be >> clearer than doing from 2 to n degree) and the size of the >> matrix (then how is sparse is another topic). >> >> >> >>> While I don't mind adding another picture, I think the >>> >> chairs will be >> >>> more interested in us reducing the length of the document than >>> expanding it ;-) . >>> >>> >> well hope it's not the main criteria (we can always shot for >> the longest >> RFC) ;-) >> >> Cheers >> G >> >> >>> Cheers >>> >>> Greg >>> >>> Giovanni Martinelli wrote: >>> >>>> Hi Greg & WSONers, >>>> >>>> well, I saw you just suggest a last call request but I was >>>> >> wondering >> >>>> about representing a more general case of ROAM in section 3.3.1 >>>> >>>> The ID currently represent a 2 degree ROADM but looks to me a very >>>> specific case so I'm asking if it's ok adding a 4 degree >>>> >> ROADM as well. >> >>>> Here just a rough idea starting from your current picture >>>> >>>> +---------------------+ Line >>>> >> side-1 ingress >> >>>> --->| |---> Line side-2 egress >>>> Line side-1 egress <---| |<--- Line side-2 >>>> ingress >>>> | ROADM | >>>> Line side-3 ingress --->| |---> Line >>>> >> side-4 egress >> >>>> Line side-3 egress <---| |<--- Line side-4 >>>> ingress >>>> | | >>>> +---------------------+ >>>> | | | | o o o o >>>> | | | | | | | | >>>> O O O O | | | | >>>> Tributary Side: Drop (egress) Add (ingress) >>>> >>>> >>>> 1/ line sides likely have ingress and egress. >>>> >>>> >>>> 2/ Tributaries might be associated to sides but I would >>>> >> consider that >> >>>> as switching constrain. >>>> >>>> Does the switching matrix will apply in the same way, >>>> >> become an 8x8 >> >>>> right?. >>>> >>>> Any thoughts about? >>>> >>>> >>>> Cheers >>>> G >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> >> >> > > > > From gregb@grotto-networking.com Mon Sep 21 11:11:56 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9FAB28C0F1 for ; Mon, 21 Sep 2009 11:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.311, 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 ZaJEkVK722Cb for ; Mon, 21 Sep 2009 11:11:55 -0700 (PDT) Received: from pro46.abac.com (pro46.abac.com [66.226.64.47]) by core3.amsl.com (Postfix) with ESMTP id 569EA3A67B2 for ; Mon, 21 Sep 2009 11:11:55 -0700 (PDT) Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id n8LIC7s5092124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Sep 2009 11:12:08 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <4AB7C1F7.9040204@grotto-networking.com> Date: Mon, 21 Sep 2009 11:12:07 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Giovanni Martinelli References: <4AAFB210.8000802@cisco.com> <4AAFB6FF.2060301@grotto-networking.com> <4AB1EC48.2050407@cisco.com> <002001ca389a$1e7eb5a0$4c0c7c0a@china.huawei.com> <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BA4@acreoexc01.ad.acreo.se> <001d01ca3ad4$2c1127c0$4c0c7c0a@china.huawei.com> <4AB7A915.9000903@cisco.com> In-Reply-To: <4AB7A915.9000903@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ccamp@ietf.org Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM 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, 21 Sep 2009 18:11:56 -0000 Hi folks, for the framework document we currently have an example of a 2-Degree unidirectional ROADM. Which represents about the simplest asymmetric switching system we can show. The general connectivity matrix formulation is at its core is unidirectional, i.e., deals with the potential connectivity of each ingress and egress pair separately to be generally applicable. Note that the encoding draft hits the issue of how to represent this stuff compactly on the wire. Note the size of the matrix is in terms of (# of ingress ports) X (# of egress ports) and don't forget to include add and drop ports. The interesting feature of higher degree ROADMs is that two ROADMs of the same "degree" may have very different connectivity properties. For example in architectures based on add/drop per node versus add/drop per fiber. In your 4-degree example Giovanni the number of add and drop ports seemed rather small and seems to make it hard to illustrate the difference between a "drop per node" and a "drop per fiber" style architecture. What aspects do you want to see illustrated most in this section of the draft? I'm thinking of adding some text to address the general case a bit more since the draft can refer to a published paper (in JOCN) that furnishes a significant number of examples of higher order and bidirectional ROADMs. Cheers Greg Giovanni Martinelli wrote: > Hi, > > Young Lee wrote: >> Hi Jonas, >> >> Yes you are right. Due to the ASCII limitation, the figures for both >> 2-degree and 4-degree ROADM are shown only for one direction. > although ascii art difficult, I got the issue in understanding where > bi-directionality apply as well. That's why I was trying to get all > directions in one picture (but not sure the result was ok). > >> For your >> question (2), we have added a note that this ROADM is based on per port >> add/drop (which is hard to show with ASCII) which means Ingress 1(2) and >> Egress 1(2) are associated to the different directions. >> > One more clarification on the topic: the fact that we represent > connectivity matrix done by (ingress x egress) it means we have a > matrix for each directions? > > thx > G > >> Hope this clarifies your question... Thanks. >> Regards, >> Young >> >> -----Original Message----- >> From: Jonas Mårtensson [mailto:Jonas.Martensson@acreo.se] Sent: >> Monday, September 21, 2009 10:21 AM >> To: Young Lee; 'Giovanni Martinelli' >> Cc: ccamp@ietf.org >> Subject: RE: [CCAMP] rwa wson framework: multi-degree ROADM >> >> Hi Young, >> >> Actually, I think the figure you propose is a bit confusing for a >> couple of >> reasons: >> >> 1) It only depicts either ingress or egress for the four directions >> while in >> practice links are typically bidirectional. (The same is true for the >> degree-2 ROADM example in the draft but there it is less confusing.) >> >> 2) The way the ports are numbered, to me it looks like Ingress 1(2) and >> Egress 1(2) are associated to the same direction which means that to >> me it >> looks more like a degree-2 ROADM. >> >> I think it would be clearer if you made all ports in the figures >> bidirectional. >> >> Regards, >> Jonas >> >> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>> Behalf Of Young Lee >>> Sent: den 18 september 2009 21:57 >>> To: 'Giovanni Martinelli' >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >>> >>> Hi Giovanni, >>> We have added 4-degree ROADM figure and connectivity matrix per your >>> suggestion in the draft. Below is tentative text we have added in >>> Section 3.3.1. I hope this would satisfy your request. >>> Thanks. >>> Young >>> ---------------------------------------------------------------- >>> >>> Ingress 1 +---------------+ +---------------+ Egress 1 >>> ----> | | -->| |----> >>> Ingress 2 | | | | Egress 2 >>> ----> | | -->| |----> >>> +---------------+ +---------------+ >>> | | | | | | O O O O O O >>> | | | | | | | | | | | | >>> O O O O O O | | | | | | >>> E3 E4 E5 E6 E7 E8 I3 I4 I5 I6 I7 I8 >>> Triburary Side Drop Add >>> Figure 2 Degree-4 ROADM >>> >>> For the ROADM of Figure 2 the switched connectivity matrix can be >>> expressed as follows. Note that this ROADM is based on per port >>> add/drop. >>> Ingress Egress Port >>> Port #1 #2 #3 #4 #5 #6 #7 #8 >>> -------------- >>> #1: 1 1 0 0 0 1 1 1 >>> #2 1 1 1 1 1 0 0 0 >>> A = #3 0 1 0 0 0 0 0 0 >>> #4 0 1 0 0 0 0 0 0 >>> #5 0 1 0 0 0 0 0 0 >>> #6 1 0 0 0 0 0 0 0 #7 1 0 >>> 0 0 0 0 0 0 #8 1 0 0 0 0 0 0 0 >>> >>> Where egress ports 3-5 are drop ports from Ingress 2 and egress >>> ports 6-8 are drop ports from Ingress 1 and ingress ports 3-5 are >>> add ports to Egress 2, ingress ports 6-8 are add ports to Egress 1. >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>> Behalf Of Giovanni Martinelli >>> Sent: Thursday, September 17, 2009 2:59 AM >>> To: Greg Bernstein >>> Cc: ccamp@ietf.org >>> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >>> >>> Hi Greg, >>> >>> Greg Bernstein wrote: >>> >>>> Hi Giovanni, in the example given in section 5 (thanks to Dirk) we >>>> have multi-degree ROADMs. In section 3.3.1 we do mention >>> higher degree >>>> ROADMs but refer readers to another draft. Hmm, maybe we >>> should also >>>> point them to section 5. >>>> >>> um well Section 5 provide more a high level overview and the scope >>> is a bit different while the other reference at the end still >>> contain 2 degree roadm (unless I'm missing something) >>> >>> This section was providing details about how a roadm is presented >>> and the respective connectivity matrix (while in other examples the >>> connectivity matrix only shows what is important for the example >>> itself). >>> >>> To me this is important to show how exactly every roadm can be >>> represented (and I guess generalizing from 4 to n will be clearer >>> than doing from 2 to n degree) and the size of the matrix (then how >>> is sparse is another topic). >>> >>> >>> >>>> While I don't mind adding another picture, I think the >>> chairs will be >>>> more interested in us reducing the length of the document than >>>> expanding it ;-) . >>>> >>>> >>> well hope it's not the main criteria (we can always shot for the >>> longest >>> RFC) ;-) >>> >>> Cheers >>> G >>> >>> >>>> Cheers >>>> >>>> Greg >>>> >>>> Giovanni Martinelli wrote: >>>> >>>>> Hi Greg & WSONers, >>>>> >>>>> well, I saw you just suggest a last call request but I was >>> wondering >>>>> about representing a more general case of ROAM in section 3.3.1 >>>>> >>>>> The ID currently represent a 2 degree ROADM but looks to me a very >>>>> specific case so I'm asking if it's ok adding a 4 degree >>> ROADM as well. >>> >>>>> Here just a rough idea starting from your current picture >>>>> >>>>> +---------------------+ Line >>> side-1 ingress >>> >>>>> --->| |---> Line side-2 egress >>>>> Line side-1 egress <---| |<--- Line side-2 >>>>> ingress >>>>> | ROADM | >>>>> Line side-3 ingress --->| |---> Line >>> side-4 egress >>> >>>>> Line side-3 egress <---| |<--- Line side-4 >>>>> ingress >>>>> | | >>>>> +---------------------+ >>>>> | | | | o o o o >>>>> | | | | | | | | >>>>> O O O O | | | | >>>>> Tributary Side: Drop (egress) Add (ingress) >>>>> >>>>> >>>>> 1/ line sides likely have ingress and egress. >>>>> >>>>> >>>>> 2/ Tributaries might be associated to sides but I would >>> consider that >>>>> as switching constrain. >>>>> >>>>> Does the switching matrix will apply in the same way, >>> become an 8x8 >>>>> right?. >>>>> >>>>> Any thoughts about? >>>>> >>>>> >>>>> Cheers >>>>> G >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >>> >> >> >> >> > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From jonas.martensson@acreo.se Tue Sep 22 01:21:22 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35A2C3A672E for ; Tue, 22 Sep 2009 01:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.453 X-Spam-Level: X-Spam-Status: No, score=-1.453 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, HELO_EQ_DK=1.009, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-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 D+OV-OZTunFG for ; Tue, 22 Sep 2009 01:21:20 -0700 (PDT) Received: from dkcphmx24.softcom.dk (dkcphmx24.softcom.dk [194.192.15.188]) by core3.amsl.com (Postfix) with ESMTP id E2D1F3A6930 for ; Tue, 22 Sep 2009 01:21:18 -0700 (PDT) Received: (qmail 29303 invoked by uid 74); 22 Sep 2009 08:22:19 -0000 Received: from mail.acreo.se (217.151.195.216) by dkcphmx24.softcom.dk (envelope-from ) with ESMTP. tag msg.1253607739.282377.424 (Processed in 0.258684 secs); 22 Sep 2009 08:22:19 -0000 X-SoftScan-Status: clean X-Secure-TLS: Yes, message received through TLS by dkcphmx24.softcom.dk (RC4-MD5) Received: from mail.acreo.se (HELO mail.acreo.se) (217.151.195.216) by dkcphmx24.softcom.dk over TLS secured channel with (RC4-MD5 encrypted) ESMTPS; Tue, 22 Sep 2009 10:22:19 +0200 Received: from acreoexc01.ad.acreo.se ([10.4.148.12]) by acreoexc01.ad.acreo.se ([10.4.148.12]) with mapi; Tue, 22 Sep 2009 10:22:18 +0200 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: Greg Bernstein , Giovanni Martinelli Date: Tue, 22 Sep 2009 10:22:17 +0200 Thread-Topic: [CCAMP] rwa wson framework: multi-degree ROADM Thread-Index: Aco65xLRwsYbBSs4ScWPNO7D1qCmCQAa2UzQ Message-ID: <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BBB@acreoexc01.ad.acreo.se> References: <4AAFB210.8000802@cisco.com> <4AAFB6FF.2060301@grotto-networking.com> <4AB1EC48.2050407@cisco.com> <002001ca389a$1e7eb5a0$4c0c7c0a@china.huawei.com> <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BA4@acreoexc01.ad.acreo.se> <001d01ca3ad4$2c1127c0$4c0c7c0a@china.huawei.com> <4AB7A915.9000903@cisco.com> <4AB7C1F7.9040204@grotto-networking.com> In-Reply-To: <4AB7C1F7.9040204@grotto-networking.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM 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, 22 Sep 2009 08:21:22 -0000 Hi, Greg, as you say, the encoding draft specifies an efficient way to represen= t the connectivity of a switching node. However, the current (uni-direction= al) examples in section 3.1.1 of the framework draft do not illustrate one = reason why the encoding draft representation is efficient, which is that th= e connectivity constraints for typical ROADM designs are "bi-directional", = i.e. if ingress port X can (or can't) be connected to egress port Y, typica= lly ingress port Y can (or can't) be connected to egress port X, assuming t= he numbering is done in such a way that ingress X and egress X correspond t= o the same line side direction or the same add/drop port. This makes the co= nnectivity matrix symmetrical (which can be taken advantage of by setting t= he directionality bits of the link sets in the encoding draft representatio= n to bidirectional). Borrowing Giovanni's (slightly modified) proposed 4-de= gree example with one (potentially multi-channel) add/drop per line side po= rt to illustrate :=20 +------------------------+ =20 Line side-1 ingress (I1) --->| |---> Line side-2 eg= ress (E2) Line side-1 egress (E1) <---| |<--- Line side-2 in= gress (I2) | ROADM | Line side-3 ingress (I3) --->| |---> Line side-4 eg= ress (E4) Line side-3 egress (E3) <---| |<--- Line side-4 in= gress (I4) | | +------------------------+ | O | O | O | O | | | | | | | | O | O | O | O | Tributary Side: E5 I5 E6 I6 E7 I7 E8 I8 Corresponding 8x8 sparse and symmetrical connectivity matrix: Ingress Egress Port Port E1 E2 E3 E4 E5 E6 E7 E8 -------------- I1 0 1 1 1 0 1 0 0 I2 1 0 1 1 0 0 1 0 A =3D I3 1 1 0 1 1 0 0 0 I4 1 1 1 0 0 0 0 1 I5 0 0 1 0 0 0 0 0 I6 1 0 0 0 0 0 0 0=20 I7 0 1 0 0 0 0 0 0=20 I8 0 0 0 1 0 0 0 0 where I5/E5 are add/drop ports to/from line side-3, I6/E6 are add/drop port= s to/from line side-1, I7/E7 are add/drop ports to/from line side-2 and I8/= E8 are add/drop ports to/from line side-4. Note that diagonal elements are = zero since I assume that loopback is not supported. If ports support loopba= ck, diagonal elements would be one. Do you think such an example would be useful? Regards, Jonas > -----Original Message----- > From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 > Sent: den 21 september 2009 20:12 > To: Giovanni Martinelli > Cc: Young Lee; ccamp@ietf.org; Jonas M=E5rtensson > Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >=20 > Hi folks, for the framework document we currently have an=20 > example of a 2-Degree unidirectional ROADM. Which represents=20 > about the simplest asymmetric switching system we can show. =20 > The general connectivity matrix formulation is at its core=20 > is unidirectional, i.e., deals with the potential=20 > connectivity of each ingress and egress pair separately to be=20 > generally applicable. Note that the encoding draft hits the=20 > issue of how to represent this stuff compactly on the wire. >=20 > Note the size of the matrix is in terms of (# of ingress=20 > ports) X (# of egress ports) and don't forget to include add=20 > and drop ports. The interesting feature of higher degree=20 > ROADMs is that two ROADMs of the same "degree" may have very=20 > different connectivity properties. For example in=20 > architectures based on add/drop per node versus add/drop per=20 > fiber. In your 4-degree example Giovanni the number of add=20 > and drop ports seemed rather small and seems to make it hard=20 > to illustrate the difference between a "drop per node" and a=20 > "drop per fiber" style architecture. >=20 > What aspects do you want to see illustrated most in this=20 > section of the draft? I'm thinking of adding some text to=20 > address the general case a bit more since the draft can refer=20 > to a published paper (in JOCN) that furnishes a significant=20 > number of examples of higher order and bidirectional ROADMs. >=20 > Cheers >=20 > Greg >=20 > Giovanni Martinelli wrote: > > Hi, > > > > Young Lee wrote: > >> Hi Jonas, > >> > >> Yes you are right. Due to the ASCII limitation, the=20 > figures for both=20 > >> 2-degree and 4-degree ROADM are shown only for one direction. > > although ascii art difficult, I got the issue in=20 > understanding where=20 > > bi-directionality apply as well. That's why I was trying to get all=20 > > directions in one picture (but not sure the result was ok). > > > >> For your > >> question (2), we have added a note that this ROADM is based on per=20 > >> port add/drop (which is hard to show with ASCII) which=20 > means Ingress=20 > >> 1(2) and Egress 1(2) are associated to the different directions. > >> =20 > > One more clarification on the topic: the fact that we represent=20 > > connectivity matrix done by (ingress x egress) it means we have a=20 > > matrix for each directions? > > > > thx > > G > > > >> Hope this clarifies your question... Thanks. > >> Regards, > >> Young > >> > >> -----Original Message----- > >> From: Jonas M=E5rtensson [mailto:Jonas.Martensson@acreo.se] Sent:=20 > >> Monday, September 21, 2009 10:21 AM > >> To: Young Lee; 'Giovanni Martinelli' > >> Cc: ccamp@ietf.org > >> Subject: RE: [CCAMP] rwa wson framework: multi-degree ROADM > >> > >> Hi Young, > >> > >> Actually, I think the figure you propose is a bit confusing for a=20 > >> couple of > >> reasons: > >> > >> 1) It only depicts either ingress or egress for the four=20 > directions=20 > >> while in practice links are typically bidirectional. (The same is=20 > >> true for the > >> degree-2 ROADM example in the draft but there it is less=20 > confusing.) > >> > >> 2) The way the ports are numbered, to me it looks like=20 > Ingress 1(2)=20 > >> and Egress 1(2) are associated to the same direction which=20 > means that=20 > >> to me it looks more like a degree-2 ROADM. > >> > >> I think it would be clearer if you made all ports in the figures=20 > >> bidirectional. > >> > >> Regards, > >> Jonas > >> > >> =20 > >>> -----Original Message----- > >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 > >>> Behalf Of Young Lee > >>> Sent: den 18 september 2009 21:57 > >>> To: 'Giovanni Martinelli' > >>> Cc: ccamp@ietf.org > >>> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM > >>> > >>> Hi Giovanni, > >>> We have added 4-degree ROADM figure and connectivity=20 > matrix per your=20 > >>> suggestion in the draft. Below is tentative text we have added in=20 > >>> Section 3.3.1. I hope this would satisfy your request. > >>> Thanks. > >>> Young > >>> ---------------------------------------------------------------- > >>> > >>> Ingress 1 +---------------+ +---------------+ Egress 1=20 > >>> ----> | | -->| |---->=20 > >>> Ingress 2 | | | | Egress 2 > >>> ----> | | -->| |----> =20 > >>> +---------------+ +---------------+ > >>> | | | | | | O O O O O O > >>> | | | | | | | | | | | | > >>> O O O O O O | | | | | | > >>> E3 E4 E5 E6 E7 E8 I3 I4 I5 I6 I7 I8 > >>> Triburary Side Drop Add > >>> Figure 2 Degree-4 ROADM > >>> > >>> For the ROADM of Figure 2 the switched connectivity matrix can be=20 > >>> expressed as follows. Note that this ROADM is based on per port=20 > >>> add/drop. > >>> Ingress Egress Port > >>> Port #1 #2 #3 #4 #5 #6 #7 #8 > >>> -------------- > >>> #1: 1 1 0 0 0 1 1 1 > >>> #2 1 1 1 1 1 0 0 0 > >>> A =3D #3 0 1 0 0 0 0 0 0 > >>> #4 0 1 0 0 0 0 0 0 > >>> #5 0 1 0 0 0 0 0 0 > >>> #6 1 0 0 0 0 0 0 0 #7 =20 > 1 0 =20 > >>> 0 0 0 0 0 0 #8 1 0 0 0 0 0 0 0 > >>> =20 > >>> Where egress ports 3-5 are drop ports from Ingress 2 and egress=20 > >>> ports 6-8 are drop ports from Ingress 1 and ingress ports 3-5 are=20 > >>> add ports to Egress 2, ingress ports 6-8 are add ports to=20 > Egress 1. > >>> > >>> -----Original Message----- > >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 > >>> Behalf Of Giovanni Martinelli > >>> Sent: Thursday, September 17, 2009 2:59 AM > >>> To: Greg Bernstein > >>> Cc: ccamp@ietf.org > >>> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM > >>> > >>> Hi Greg, > >>> > >>> Greg Bernstein wrote: > >>> =20 > >>>> Hi Giovanni, in the example given in section 5 (thanks=20 > to Dirk) we=20 > >>>> have multi-degree ROADMs. In section 3.3.1 we do mention =20 > >>> higher degree =20 > >>>> ROADMs but refer readers to another draft. Hmm, maybe we =20 > >>> should also =20 > >>>> point them to section 5. > >>>> =20 > >>> um well Section 5 provide more a high level overview and=20 > the scope=20 > >>> is a bit different while the other reference at the end still=20 > >>> contain 2 degree roadm (unless I'm missing something) > >>> > >>> This section was providing details about how a roadm is presented=20 > >>> and the respective connectivity matrix (while in other=20 > examples the=20 > >>> connectivity matrix only shows what is important for the example=20 > >>> itself). > >>> > >>> To me this is important to show how exactly every roadm can be=20 > >>> represented (and I guess generalizing from 4 to n will be clearer=20 > >>> than doing from 2 to n degree) and the size of the=20 > matrix (then how=20 > >>> is sparse is another topic). > >>> > >>> > >>> =20 > >>>> While I don't mind adding another picture, I think the =20 > >>> chairs will be =20 > >>>> more interested in us reducing the length of the document than=20 > >>>> expanding it ;-) . > >>>> > >>>> =20 > >>> well hope it's not the main criteria (we can always shot for the=20 > >>> longest > >>> RFC) ;-) > >>> > >>> Cheers > >>> G > >>> > >>> =20 > >>>> Cheers > >>>> > >>>> Greg > >>>> > >>>> Giovanni Martinelli wrote: > >>>> =20 > >>>>> Hi Greg & WSONers, > >>>>> > >>>>> well, I saw you just suggest a last call request but I=20 > was =20 > >>> wondering =20 > >>>>> about representing a more general case of ROAM in section 3.3.1 > >>>>> > >>>>> The ID currently represent a 2 degree ROADM but looks=20 > to me a very=20 > >>>>> specific case so I'm asking if it's ok adding a 4=20 > degree =20 > >>> ROADM as well. > >>> =20 > >>>>> Here just a rough idea starting from your current picture > >>>>> > >>>>> +---------------------+ Line =20 > >>> side-1 ingress > >>> =20 > >>>>> --->| |---> Line side-2 egress > >>>>> Line side-1 egress <---| |<--- =20 > Line side-2=20 > >>>>> ingress > >>>>> | ROADM | > >>>>> Line side-3 ingress --->| |---> =20 > Line =20 > >>> side-4 egress > >>> =20 > >>>>> Line side-3 egress <---| |<--- =20 > Line side-4=20 > >>>>> ingress > >>>>> | | > >>>>> +---------------------+ > >>>>> | | | | o o o o > >>>>> | | | | | | | | > >>>>> O O O O | | | | > >>>>> Tributary Side: Drop (egress) Add (ingress) > >>>>> > >>>>> > >>>>> 1/ line sides likely have ingress and egress. > >>>>> > >>>>> > >>>>> 2/ Tributaries might be associated to sides but I would =20 > >>> consider that =20 > >>>>> as switching constrain. > >>>>> > >>>>> Does the switching matrix will apply in the same way, =20 > >>> become an 8x8 =20 > >>>>> right?. > >>>>> > >>>>> Any thoughts about? > >>>>> > >>>>> > >>>>> Cheers > >>>>> G > >>>>> _______________________________________________ > >>>>> CCAMP mailing list > >>>>> CCAMP@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>>> > >>>>> =20 > >>> _______________________________________________ > >>> CCAMP mailing list > >>> CCAMP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ccamp > >>> > >>> > >>> _______________________________________________ > >>> CCAMP mailing list > >>> CCAMP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ccamp > >>> > >>> > >>> =20 > >> > >> > >> > >> =20 > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > >=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 >=20 >=20 >=20 > = From giomarti@cisco.com Tue Sep 22 07:32:01 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6E63A6954 for ; Tue, 22 Sep 2009 07:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy9zUdkf44L2 for ; Tue, 22 Sep 2009 07:31:59 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 09E743A67DA for ; Tue, 22 Sep 2009 07:31:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQAAPx8uEqQ/uCLe2dsb2JhbACacwEBFiQGpBuITwGPfwWEGw X-IronPort-AV: E=Sophos;i="4.44,431,1249257600"; d="scan'208";a="49968711" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Sep 2009 14:33:01 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8MEX1aH017497; Tue, 22 Sep 2009 16:33:01 +0200 Received: from [10.61.96.242] (dhcp-10-61-96-242.cisco.com [10.61.96.242]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8MEX03p027246; Tue, 22 Sep 2009 14:33:01 GMT Message-ID: <4AB8E01C.6050900@cisco.com> Date: Tue, 22 Sep 2009 16:33:00 +0200 From: Giovanni Martinelli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Greg Bernstein References: <4AAFB210.8000802@cisco.com> <4AAFB6FF.2060301@grotto-networking.com> <4AB1EC48.2050407@cisco.com> <002001ca389a$1e7eb5a0$4c0c7c0a@china.huawei.com> <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BA4@acreoexc01.ad.acreo.se> <001d01ca3ad4$2c1127c0$4c0c7c0a@china.huawei.com> <4AB7A915.9000903@cisco.com> <4AB7C1F7.9040204@grotto-networking.com> In-Reply-To: <4AB7C1F7.9040204@grotto-networking.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10036; t=1253629981; x=1254493981; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=giomarti@cisco.com; z=From:=20Giovanni=20Martinelli=20 |Subject:=20Re=3A=20[CCAMP]=20rwa=20wson=20framework=3A=20m ulti-degree=20ROADM |Sender:=20; bh=XDfTiDbJ55Eh96S7mLr6ZOpAzXK8jzfhovKHhksoyeQ=; b=spZTdyfC+vaoZZdg00xpWMKJIB0bfjSooWNB+6vlNSAdUSt9cu0BSRQa/6 rLh/m3x2RIyqtDcGpaUsxvlCQ7146RaScHXcvkXcy+Vn8ryVqr5ixYjblAvQ MqDJs50WSV; Authentication-Results: ams-dkim-2; header.From=giomarti@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ccamp@ietf.org Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM 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, 22 Sep 2009 14:32:01 -0000 Hi Greg Bernstein wrote: > Hi folks, for the framework document we currently have an example of a > 2-Degree unidirectional ROADM. Which represents about the simplest > asymmetric switching system we can show. The general connectivity > matrix formulation is at its core is unidirectional, i.e., deals > with the potential connectivity of each ingress and egress pair > separately to be generally applicable. Note that the encoding draft > hits the issue of how to represent this stuff compactly on the wire. > > Note the size of the matrix is in terms of (# of ingress ports) X (# > of egress ports) and don't forget to include add and drop ports. The > interesting feature of higher degree ROADMs is that two ROADMs of the > same "degree" may have very different connectivity properties. For > example in architectures based on add/drop per node versus add/drop > per fiber. In your 4-degree example Giovanni the number of add and > drop ports seemed rather small and seems to make it hard to illustrate > the difference between a "drop per node" and a "drop per fiber" style > architecture. yes I realized I was not so clear... tributary ports can be in really high numbers and even there could be several switching constrains on tributary vs lines. thx G > > What aspects do you want to see illustrated most in this section of > the draft? I'm thinking of adding some text to address the general > case a bit more since the draft can refer to a published paper (in > JOCN) that furnishes a significant number of examples of higher order > and bidirectional ROADMs. > > Cheers > > Greg > > Giovanni Martinelli wrote: >> Hi, >> >> Young Lee wrote: >>> Hi Jonas, >>> >>> Yes you are right. Due to the ASCII limitation, the figures for both >>> 2-degree and 4-degree ROADM are shown only for one direction. >> although ascii art difficult, I got the issue in understanding where >> bi-directionality apply as well. That's why I was trying to get all >> directions in one picture (but not sure the result was ok). >> >>> For your >>> question (2), we have added a note that this ROADM is based on per port >>> add/drop (which is hard to show with ASCII) which means Ingress 1(2) >>> and >>> Egress 1(2) are associated to the different directions. >>> >> One more clarification on the topic: the fact that we represent >> connectivity matrix done by (ingress x egress) it means we have a >> matrix for each directions? >> >> thx >> G >> >>> Hope this clarifies your question... Thanks. >>> Regards, >>> Young >>> >>> -----Original Message----- >>> From: Jonas Mårtensson [mailto:Jonas.Martensson@acreo.se] Sent: >>> Monday, September 21, 2009 10:21 AM >>> To: Young Lee; 'Giovanni Martinelli' >>> Cc: ccamp@ietf.org >>> Subject: RE: [CCAMP] rwa wson framework: multi-degree ROADM >>> >>> Hi Young, >>> >>> Actually, I think the figure you propose is a bit confusing for a >>> couple of >>> reasons: >>> >>> 1) It only depicts either ingress or egress for the four directions >>> while in >>> practice links are typically bidirectional. (The same is true for the >>> degree-2 ROADM example in the draft but there it is less confusing.) >>> >>> 2) The way the ports are numbered, to me it looks like Ingress 1(2) and >>> Egress 1(2) are associated to the same direction which means that to >>> me it >>> looks more like a degree-2 ROADM. >>> >>> I think it would be clearer if you made all ports in the figures >>> bidirectional. >>> >>> Regards, >>> Jonas >>> >>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>> Behalf Of Young Lee >>>> Sent: den 18 september 2009 21:57 >>>> To: 'Giovanni Martinelli' >>>> Cc: ccamp@ietf.org >>>> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >>>> >>>> Hi Giovanni, >>>> We have added 4-degree ROADM figure and connectivity matrix per >>>> your suggestion in the draft. Below is tentative text we have added >>>> in Section 3.3.1. I hope this would satisfy your request. >>>> Thanks. >>>> Young >>>> ---------------------------------------------------------------- >>>> >>>> Ingress 1 +---------------+ +---------------+ Egress 1 >>>> ----> | | -->| |----> >>>> Ingress 2 | | | | Egress 2 >>>> ----> | | -->| |----> >>>> +---------------+ +---------------+ >>>> | | | | | | O O O O O O >>>> | | | | | | | | | | | | >>>> O O O O O O | | | | | | >>>> E3 E4 E5 E6 E7 E8 I3 I4 I5 I6 I7 I8 >>>> Triburary Side Drop Add >>>> Figure 2 Degree-4 ROADM >>>> >>>> For the ROADM of Figure 2 the switched connectivity matrix can be >>>> expressed as follows. Note that this ROADM is based on per port >>>> add/drop. >>>> Ingress Egress Port >>>> Port #1 #2 #3 #4 #5 #6 #7 #8 >>>> -------------- >>>> #1: 1 1 0 0 0 1 1 1 >>>> #2 1 1 1 1 1 0 0 0 >>>> A = #3 0 1 0 0 0 0 0 0 >>>> #4 0 1 0 0 0 0 0 0 >>>> #5 0 1 0 0 0 0 0 0 >>>> #6 1 0 0 0 0 0 0 0 #7 1 0 >>>> 0 0 0 0 0 0 #8 1 0 0 0 0 0 0 0 >>>> Where egress ports 3-5 are drop ports from Ingress 2 and egress >>>> ports 6-8 are drop ports from Ingress 1 and ingress ports 3-5 are >>>> add ports to Egress 2, ingress ports 6-8 are add ports to Egress 1. >>>> >>>> -----Original Message----- >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>> Behalf Of Giovanni Martinelli >>>> Sent: Thursday, September 17, 2009 2:59 AM >>>> To: Greg Bernstein >>>> Cc: ccamp@ietf.org >>>> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >>>> >>>> Hi Greg, >>>> >>>> Greg Bernstein wrote: >>>> >>>>> Hi Giovanni, in the example given in section 5 (thanks to Dirk) we >>>>> have multi-degree ROADMs. In section 3.3.1 we do mention >>>> higher degree >>>>> ROADMs but refer readers to another draft. Hmm, maybe we >>>> should also >>>>> point them to section 5. >>>>> >>>> um well Section 5 provide more a high level overview and the scope >>>> is a bit different while the other reference at the end still >>>> contain 2 degree roadm (unless I'm missing something) >>>> >>>> This section was providing details about how a roadm is presented >>>> and the respective connectivity matrix (while in other examples the >>>> connectivity matrix only shows what is important for the example >>>> itself). >>>> >>>> To me this is important to show how exactly every roadm can be >>>> represented (and I guess generalizing from 4 to n will be clearer >>>> than doing from 2 to n degree) and the size of the matrix (then >>>> how is sparse is another topic). >>>> >>>> >>>> >>>>> While I don't mind adding another picture, I think the >>>> chairs will be >>>>> more interested in us reducing the length of the document than >>>>> expanding it ;-) . >>>>> >>>>> >>>> well hope it's not the main criteria (we can always shot for the >>>> longest >>>> RFC) ;-) >>>> >>>> Cheers >>>> G >>>> >>>> >>>>> Cheers >>>>> >>>>> Greg >>>>> >>>>> Giovanni Martinelli wrote: >>>>> >>>>>> Hi Greg & WSONers, >>>>>> >>>>>> well, I saw you just suggest a last call request but I was >>>> wondering >>>>>> about representing a more general case of ROAM in section 3.3.1 >>>>>> >>>>>> The ID currently represent a 2 degree ROADM but looks to me a >>>>>> very specific case so I'm asking if it's ok adding a 4 >>>>>> degree >>>> ROADM as well. >>>> >>>>>> Here just a rough idea starting from your current picture >>>>>> >>>>>> +---------------------+ Line >>>> side-1 ingress >>>> >>>>>> --->| |---> Line side-2 egress >>>>>> Line side-1 egress <---| |<--- Line side-2 >>>>>> ingress >>>>>> | ROADM | >>>>>> Line side-3 ingress --->| |---> Line >>>> side-4 egress >>>> >>>>>> Line side-3 egress <---| |<--- Line side-4 >>>>>> ingress >>>>>> | | >>>>>> +---------------------+ >>>>>> | | | | o o o o >>>>>> | | | | | | | | >>>>>> O O O O | | | | >>>>>> Tributary Side: Drop (egress) Add (ingress) >>>>>> >>>>>> >>>>>> 1/ line sides likely have ingress and egress. >>>>>> >>>>>> >>>>>> 2/ Tributaries might be associated to sides but I would >>>> consider that >>>>>> as switching constrain. >>>>>> >>>>>> Does the switching matrix will apply in the same way, >>>> become an 8x8 >>>>>> right?. >>>>>> >>>>>> Any thoughts about? >>>>>> >>>>>> >>>>>> Cheers >>>>>> G >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>>> >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> >>>> >>> >>> >>> >>> >> _______________________________________________ >> CCAMP mailing list >> CCAMP@ietf.org >> https://www.ietf.org/mailman/listinfo/ccamp >> > From giomarti@cisco.com Tue Sep 22 07:38:20 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EED3E3A691C for ; Tue, 22 Sep 2009 07:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 FgVugkwUzVBF for ; Tue, 22 Sep 2009 07:38:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 886B33A67AD for ; Tue, 22 Sep 2009 07:38:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQAACx+uEqQ/uCKe2dsb2JhbACacwEBCwskBqQniE8BMgmPRAWCR4FU X-IronPort-AV: E=Sophos;i="4.44,431,1249257600"; d="scan'208";a="49969301" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Sep 2009 14:39:21 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8MEdLSw014665; Tue, 22 Sep 2009 16:39:21 +0200 Received: from [10.61.96.242] (dhcp-10-61-96-242.cisco.com [10.61.96.242]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8MEdJUM028908; Tue, 22 Sep 2009 14:39:20 GMT Message-ID: <4AB8E197.8040800@cisco.com> Date: Tue, 22 Sep 2009 16:39:19 +0200 From: Giovanni Martinelli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jonas_M=E5rtensson?= References: <4AAFB210.8000802@cisco.com> <4AAFB6FF.2060301@grotto-networking.com> <4AB1EC48.2050407@cisco.com> <002001ca389a$1e7eb5a0$4c0c7c0a@china.huawei.com> <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BA4@acreoexc01.ad.acreo.se> <001d01ca3ad4$2c1127c0$4c0c7c0a@china.huawei.com> <4AB7A915.9000903@cisco.com> <4AB7C1F7.9040204@grotto-networking.com> <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BBB@acreoexc01.ad.acreo.se> In-Reply-To: <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BBB@acreoexc01.ad.acreo.se> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14800; t=1253630361; x=1254494361; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=giomarti@cisco.com; z=From:=20Giovanni=20Martinelli=20 |Subject:=20Re=3A=20[CCAMP]=20rwa=20wson=20framework=3A=20m ulti-degree=20ROADM |Sender:=20; bh=Cn/qagdPOeqRtUYBP/YpAs3//nnSRSSSGbxGlAcqrMU=; b=EzmfJxJUgfGjqWmTk9BoEBq8dHM9n7SCQsZi1uW3cp9iNpPoSr2S2n583T bMjuD2oHXmaiZi75hd5BqJu59nZ1vYhrZPq3OCad4rwwbK0m1Tz24eShjqkp jTs4gqgity; Authentication-Results: ams-dkim-1; header.From=giomarti@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM 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, 22 Sep 2009 14:38:21 -0000 Jonas Mårtensson wrote: > Hi, > > Greg, as you say, the encoding draft specifies an efficient way to represent the connectivity of a switching node. However, the current (uni-directional) examples in section 3.1.1 of the framework draft do not illustrate one reason why the encoding draft representation is efficient, which is that the connectivity constraints for typical ROADM designs are "bi-directional", i.e. if ingress port X can (or can't) be connected to egress port Y, typically ingress port Y can (or can't) be connected to egress port X, assuming the numbering is done in such a way that ingress X and egress X correspond to the same line side direction or the same add/drop port. This makes the connectivity matrix symmetrical (which can be taken advantage of by setting the directionality bits of the link sets in the encoding draft representation to bidirectional). Which means that changing directions we need to transpose the matrix, right? > Borrowing Giovanni's (slightly modified) proposed 4-degree example with one (potentially multi-channel) add/drop per line side port to illustrate : > > > +------------------------+ > Line side-1 ingress (I1) --->| |---> Line side-2 egress (E2) > Line side-1 egress (E1) <---| |<--- Line side-2 ingress (I2) > | ROADM | > Line side-3 ingress (I3) --->| |---> Line side-4 egress (E4) > Line side-3 egress (E3) <---| |<--- Line side-4 ingress (I4) > | | > +------------------------+ > | O | O | O | O > | | | | | | | | > O | O | O | O | > Tributary Side: E5 I5 E6 I6 E7 I7 E8 I8 > > > Corresponding 8x8 sparse and symmetrical connectivity matrix: > > Ingress Egress Port > Port E1 E2 E3 E4 E5 E6 E7 E8 > -------------- > I1 0 1 1 1 0 1 0 0 > I2 1 0 1 1 0 0 1 0 > A = I3 1 1 0 1 1 0 0 0 > I4 1 1 1 0 0 0 0 1 > I5 0 0 1 0 0 0 0 0 > I6 1 0 0 0 0 0 0 0 > I7 0 1 0 0 0 0 0 0 > I8 0 0 0 1 0 0 0 0 > > where I5/E5 are add/drop ports to/from line side-3, I6/E6 are add/drop ports to/from line side-1, I7/E7 are add/drop ports to/from line side-2 and I8/E8 are add/drop ports to/from line side-4. Note that diagonal elements are zero since I assume that loopback is not supported. If ports support loopback, diagonal elements would be one. > > Do you think such an example would be useful? > to me yes I like in this way... don't know if others have different opinions. (not sure if, according to previous mail from Greg, there's the need to have few more tributaries but the general picture is ok to me). thx G > Regards, > Jonas > > > >> -----Original Message----- >> From: Greg Bernstein [mailto:gregb@grotto-networking.com] >> Sent: den 21 september 2009 20:12 >> To: Giovanni Martinelli >> Cc: Young Lee; ccamp@ietf.org; Jonas Mårtensson >> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >> >> Hi folks, for the framework document we currently have an >> example of a 2-Degree unidirectional ROADM. Which represents >> about the simplest asymmetric switching system we can show. >> The general connectivity matrix formulation is at its core >> is unidirectional, i.e., deals with the potential >> connectivity of each ingress and egress pair separately to be >> generally applicable. Note that the encoding draft hits the >> issue of how to represent this stuff compactly on the wire. >> >> Note the size of the matrix is in terms of (# of ingress >> ports) X (# of egress ports) and don't forget to include add >> and drop ports. The interesting feature of higher degree >> ROADMs is that two ROADMs of the same "degree" may have very >> different connectivity properties. For example in >> architectures based on add/drop per node versus add/drop per >> fiber. In your 4-degree example Giovanni the number of add >> and drop ports seemed rather small and seems to make it hard >> to illustrate the difference between a "drop per node" and a >> "drop per fiber" style architecture. >> >> What aspects do you want to see illustrated most in this >> section of the draft? I'm thinking of adding some text to >> address the general case a bit more since the draft can refer >> to a published paper (in JOCN) that furnishes a significant >> number of examples of higher order and bidirectional ROADMs. >> >> Cheers >> >> Greg >> >> Giovanni Martinelli wrote: >> >>> Hi, >>> >>> Young Lee wrote: >>> >>>> Hi Jonas, >>>> >>>> Yes you are right. Due to the ASCII limitation, the >>>> >> figures for both >> >>>> 2-degree and 4-degree ROADM are shown only for one direction. >>>> >>> although ascii art difficult, I got the issue in >>> >> understanding where >> >>> bi-directionality apply as well. That's why I was trying to get all >>> directions in one picture (but not sure the result was ok). >>> >>> >>>> For your >>>> question (2), we have added a note that this ROADM is based on per >>>> port add/drop (which is hard to show with ASCII) which >>>> >> means Ingress >> >>>> 1(2) and Egress 1(2) are associated to the different directions. >>>> >>>> >>> One more clarification on the topic: the fact that we represent >>> connectivity matrix done by (ingress x egress) it means we have a >>> matrix for each directions? >>> >>> thx >>> G >>> >>> >>>> Hope this clarifies your question... Thanks. >>>> Regards, >>>> Young >>>> >>>> -----Original Message----- >>>> From: Jonas Mårtensson [mailto:Jonas.Martensson@acreo.se] Sent: >>>> Monday, September 21, 2009 10:21 AM >>>> To: Young Lee; 'Giovanni Martinelli' >>>> Cc: ccamp@ietf.org >>>> Subject: RE: [CCAMP] rwa wson framework: multi-degree ROADM >>>> >>>> Hi Young, >>>> >>>> Actually, I think the figure you propose is a bit confusing for a >>>> couple of >>>> reasons: >>>> >>>> 1) It only depicts either ingress or egress for the four >>>> >> directions >> >>>> while in practice links are typically bidirectional. (The same is >>>> true for the >>>> degree-2 ROADM example in the draft but there it is less >>>> >> confusing.) >> >>>> 2) The way the ports are numbered, to me it looks like >>>> >> Ingress 1(2) >> >>>> and Egress 1(2) are associated to the same direction which >>>> >> means that >> >>>> to me it looks more like a degree-2 ROADM. >>>> >>>> I think it would be clearer if you made all ports in the figures >>>> bidirectional. >>>> >>>> Regards, >>>> Jonas >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>> Behalf Of Young Lee >>>>> Sent: den 18 september 2009 21:57 >>>>> To: 'Giovanni Martinelli' >>>>> Cc: ccamp@ietf.org >>>>> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >>>>> >>>>> Hi Giovanni, >>>>> We have added 4-degree ROADM figure and connectivity >>>>> >> matrix per your >> >>>>> suggestion in the draft. Below is tentative text we have added in >>>>> Section 3.3.1. I hope this would satisfy your request. >>>>> Thanks. >>>>> Young >>>>> ---------------------------------------------------------------- >>>>> >>>>> Ingress 1 +---------------+ +---------------+ Egress 1 >>>>> ----> | | -->| |----> >>>>> Ingress 2 | | | | Egress 2 >>>>> ----> | | -->| |----> >>>>> +---------------+ +---------------+ >>>>> | | | | | | O O O O O O >>>>> | | | | | | | | | | | | >>>>> O O O O O O | | | | | | >>>>> E3 E4 E5 E6 E7 E8 I3 I4 I5 I6 I7 I8 >>>>> Triburary Side Drop Add >>>>> Figure 2 Degree-4 ROADM >>>>> >>>>> For the ROADM of Figure 2 the switched connectivity matrix can be >>>>> expressed as follows. Note that this ROADM is based on per port >>>>> add/drop. >>>>> Ingress Egress Port >>>>> Port #1 #2 #3 #4 #5 #6 #7 #8 >>>>> -------------- >>>>> #1: 1 1 0 0 0 1 1 1 >>>>> #2 1 1 1 1 1 0 0 0 >>>>> A = #3 0 1 0 0 0 0 0 0 >>>>> #4 0 1 0 0 0 0 0 0 >>>>> #5 0 1 0 0 0 0 0 0 >>>>> #6 1 0 0 0 0 0 0 0 #7 >>>>> >> 1 0 >> >>>>> 0 0 0 0 0 0 #8 1 0 0 0 0 0 0 0 >>>>> >>>>> Where egress ports 3-5 are drop ports from Ingress 2 and egress >>>>> ports 6-8 are drop ports from Ingress 1 and ingress ports 3-5 are >>>>> add ports to Egress 2, ingress ports 6-8 are add ports to >>>>> >> Egress 1. >> >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>>>> Behalf Of Giovanni Martinelli >>>>> Sent: Thursday, September 17, 2009 2:59 AM >>>>> To: Greg Bernstein >>>>> Cc: ccamp@ietf.org >>>>> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >>>>> >>>>> Hi Greg, >>>>> >>>>> Greg Bernstein wrote: >>>>> >>>>> >>>>>> Hi Giovanni, in the example given in section 5 (thanks >>>>>> >> to Dirk) we >> >>>>>> have multi-degree ROADMs. In section 3.3.1 we do mention >>>>>> >>>>> higher degree >>>>> >>>>>> ROADMs but refer readers to another draft. Hmm, maybe we >>>>>> >>>>> should also >>>>> >>>>>> point them to section 5. >>>>>> >>>>>> >>>>> um well Section 5 provide more a high level overview and >>>>> >> the scope >> >>>>> is a bit different while the other reference at the end still >>>>> contain 2 degree roadm (unless I'm missing something) >>>>> >>>>> This section was providing details about how a roadm is presented >>>>> and the respective connectivity matrix (while in other >>>>> >> examples the >> >>>>> connectivity matrix only shows what is important for the example >>>>> itself). >>>>> >>>>> To me this is important to show how exactly every roadm can be >>>>> represented (and I guess generalizing from 4 to n will be clearer >>>>> than doing from 2 to n degree) and the size of the >>>>> >> matrix (then how >> >>>>> is sparse is another topic). >>>>> >>>>> >>>>> >>>>> >>>>>> While I don't mind adding another picture, I think the >>>>>> >>>>> chairs will be >>>>> >>>>>> more interested in us reducing the length of the document than >>>>>> expanding it ;-) . >>>>>> >>>>>> >>>>>> >>>>> well hope it's not the main criteria (we can always shot for the >>>>> longest >>>>> RFC) ;-) >>>>> >>>>> Cheers >>>>> G >>>>> >>>>> >>>>> >>>>>> Cheers >>>>>> >>>>>> Greg >>>>>> >>>>>> Giovanni Martinelli wrote: >>>>>> >>>>>> >>>>>>> Hi Greg & WSONers, >>>>>>> >>>>>>> well, I saw you just suggest a last call request but I >>>>>>> >> was >> >>>>> wondering >>>>> >>>>>>> about representing a more general case of ROAM in section 3.3.1 >>>>>>> >>>>>>> The ID currently represent a 2 degree ROADM but looks >>>>>>> >> to me a very >> >>>>>>> specific case so I'm asking if it's ok adding a 4 >>>>>>> >> degree >> >>>>> ROADM as well. >>>>> >>>>> >>>>>>> Here just a rough idea starting from your current picture >>>>>>> >>>>>>> +---------------------+ Line >>>>>>> >>>>> side-1 ingress >>>>> >>>>> >>>>>>> --->| |---> Line side-2 egress >>>>>>> Line side-1 egress <---| |<--- >>>>>>> >> Line side-2 >> >>>>>>> ingress >>>>>>> | ROADM | >>>>>>> Line side-3 ingress --->| |---> >>>>>>> >> Line >> >>>>> side-4 egress >>>>> >>>>> >>>>>>> Line side-3 egress <---| |<--- >>>>>>> >> Line side-4 >> >>>>>>> ingress >>>>>>> | | >>>>>>> +---------------------+ >>>>>>> | | | | o o o o >>>>>>> | | | | | | | | >>>>>>> O O O O | | | | >>>>>>> Tributary Side: Drop (egress) Add (ingress) >>>>>>> >>>>>>> >>>>>>> 1/ line sides likely have ingress and egress. >>>>>>> >>>>>>> >>>>>>> 2/ Tributaries might be associated to sides but I would >>>>>>> >>>>> consider that >>>>> >>>>>>> as switching constrain. >>>>>>> >>>>>>> Does the switching matrix will apply in the same way, >>>>>>> >>>>> become an 8x8 >>>>> >>>>>>> right?. >>>>>>> >>>>>>> Any thoughts about? >>>>>>> >>>>>>> >>>>>>> Cheers >>>>>>> G >>>>>>> _______________________________________________ >>>>>>> CCAMP mailing list >>>>>>> CCAMP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>> >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> >> -- >> =================================================== >> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >> >> >> >> >> > > From gregb@grotto-networking.com Tue Sep 22 07:51:19 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6093A6A5A for ; Tue, 22 Sep 2009 07:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 pCQuSb9ocwYk for ; Tue, 22 Sep 2009 07:51:17 -0700 (PDT) Received: from pro46.abac.com (pro46.abac.com [66.226.64.47]) by core3.amsl.com (Postfix) with ESMTP id 072E03A69CE for ; Tue, 22 Sep 2009 07:51:16 -0700 (PDT) Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133] (may be forged)) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id n8MEpGmw070928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Sep 2009 07:51:20 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <4AB8E466.3020509@grotto-networking.com> Date: Tue, 22 Sep 2009 07:51:18 -0700 From: Greg Bernstein User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Jonas_M=E5rtensson?= References: <4AAFB210.8000802@cisco.com> <4AAFB6FF.2060301@grotto-networking.com> <4AB1EC48.2050407@cisco.com> <002001ca389a$1e7eb5a0$4c0c7c0a@china.huawei.com> <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BA4@acreoexc01.ad.acreo.se> <001d01ca3ad4$2c1127c0$4c0c7c0a@china.huawei.com> <4AB7A915.9000903@cisco.com> <4AB7C1F7.9040204@grotto-networking.com> <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BBB@acreoexc01.ad.acreo.se> In-Reply-To: <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BBB@acreoexc01.ad.acreo.se> Content-Type: multipart/alternative; boundary="------------000107050906070005020504" Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM 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, 22 Sep 2009 14:51:19 -0000 This is a multi-part message in MIME format. --------------000107050906070005020504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Thanks Jonas, this example seems good in that it illustrates: (a) Bi-directional ROADM (b) Higher degree ROADM (c) A more complicated connectivity matrix due to the per port type of=20 add/drop connectivity. Although the number of add/drop ports is low we could comment in the=20 text that this is for simplicity in drawing the figure. I was thinking of then adding this example to section 3.3.1 after the=20 simple example of the unidirectional 2-degree ROADM. How does that sound to you? Giovanni, Young, and others, does that=20 sound good to you? Best Regards Greg Jonas M=E5rtensson wrote: > Hi, > > Greg, as you say, the encoding draft specifies an efficient way to repr= esent the connectivity of a switching node. However, the current (uni-dir= ectional) examples in section 3.1.1 of the framework draft do not illustr= ate one reason why the encoding draft representation is efficient, which = is that the connectivity constraints for typical ROADM designs are "bi-di= rectional", i.e. if ingress port X can (or can't) be connected to egress = port Y, typically ingress port Y can (or can't) be connected to egress po= rt X, assuming the numbering is done in such a way that ingress X and egr= ess X correspond to the same line side direction or the same add/drop por= t. This makes the connectivity matrix symmetrical (which can be taken adv= antage of by setting the directionality bits of the link sets in the enco= ding draft representation to bidirectional). Borrowing Giovanni's (slight= ly modified) proposed 4-degree example with one (potentially multi-channe= l) add/drop per line side port to illustrate :=20 > > > +------------------------+ =20 > Line side-1 ingress (I1) --->| |---> Line side-= 2 egress (E2) > Line side-1 egress (E1) <---| |<--- Line side-= 2 ingress (I2) > | ROADM | > Line side-3 ingress (I3) --->| |---> Line side-= 4 egress (E4) > Line side-3 egress (E3) <---| |<--- Line side-= 4 ingress (I4) > | | > +------------------------+ > | O | O | O | O > | | | | | | | | > O | O | O | O | > Tributary Side: E5 I5 E6 I6 E7 I7 E8 I8 > > > Corresponding 8x8 sparse and symmetrical connectivity matrix: > > Ingress Egress Port > Port E1 E2 E3 E4 E5 E6 E7 E8 > -------------- > I1 0 1 1 1 0 1 0 0 > I2 1 0 1 1 0 0 1 0 > A =3D I3 1 1 0 1 1 0 0 0 > I4 1 1 1 0 0 0 0 1 > I5 0 0 1 0 0 0 0 0 > I6 1 0 0 0 0 0 0 0=20 > I7 0 1 0 0 0 0 0 0=20 > I8 0 0 0 1 0 0 0 0 > > where I5/E5 are add/drop ports to/from line side-3, I6/E6 are add/drop = ports to/from line side-1, I7/E7 are add/drop ports to/from line side-2 a= nd I8/E8 are add/drop ports to/from line side-4. Note that diagonal eleme= nts are zero since I assume that loopback is not supported. If ports supp= ort loopback, diagonal elements would be one. > > Do you think such an example would be useful? > > Regards, > Jonas > > > =20 >> -----Original Message----- >> From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 >> Sent: den 21 september 2009 20:12 >> To: Giovanni Martinelli >> Cc: Young Lee; ccamp@ietf.org; Jonas M=E5rtensson >> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >> >> Hi folks, for the framework document we currently have an=20 >> example of a 2-Degree unidirectional ROADM. Which represents=20 >> about the simplest asymmetric switching system we can show. =20 >> The general connectivity matrix formulation is at its core=20 >> is unidirectional, i.e., deals with the potential=20 >> connectivity of each ingress and egress pair separately to be=20 >> generally applicable. Note that the encoding draft hits the=20 >> issue of how to represent this stuff compactly on the wire. >> >> Note the size of the matrix is in terms of (# of ingress=20 >> ports) X (# of egress ports) and don't forget to include add=20 >> and drop ports. The interesting feature of higher degree=20 >> ROADMs is that two ROADMs of the same "degree" may have very=20 >> different connectivity properties. For example in=20 >> architectures based on add/drop per node versus add/drop per=20 >> fiber. In your 4-degree example Giovanni the number of add=20 >> and drop ports seemed rather small and seems to make it hard=20 >> to illustrate the difference between a "drop per node" and a=20 >> "drop per fiber" style architecture. >> >> What aspects do you want to see illustrated most in this=20 >> section of the draft? I'm thinking of adding some text to=20 >> address the general case a bit more since the draft can refer=20 >> to a published paper (in JOCN) that furnishes a significant=20 >> number of examples of higher order and bidirectional ROADMs. >> >> Cheers >> >> Greg >> >> Giovanni Martinelli wrote: >> =20 >>> Hi, >>> >>> Young Lee wrote: >>> =20 >>>> Hi Jonas, >>>> >>>> Yes you are right. Due to the ASCII limitation, the=20 >>>> =20 >> figures for both=20 >> =20 >>>> 2-degree and 4-degree ROADM are shown only for one direction. >>>> =20 >>> although ascii art difficult, I got the issue in=20 >>> =20 >> understanding where=20 >> =20 >>> bi-directionality apply as well. That's why I was trying to get all=20 >>> directions in one picture (but not sure the result was ok). >>> >>> =20 >>>> For your >>>> question (2), we have added a note that this ROADM is based on per=20 >>>> port add/drop (which is hard to show with ASCII) which=20 >>>> =20 >> means Ingress=20 >> =20 >>>> 1(2) and Egress 1(2) are associated to the different directions. >>>> =20 >>>> =20 >>> One more clarification on the topic: the fact that we represent=20 >>> connectivity matrix done by (ingress x egress) it means we have a=20 >>> matrix for each directions? >>> >>> thx >>> G >>> >>> =20 >>>> Hope this clarifies your question... Thanks. >>>> Regards, >>>> Young >>>> >>>> -----Original Message----- >>>> From: Jonas M=E5rtensson [mailto:Jonas.Martensson@acreo.se] Sent:=20 >>>> Monday, September 21, 2009 10:21 AM >>>> To: Young Lee; 'Giovanni Martinelli' >>>> Cc: ccamp@ietf.org >>>> Subject: RE: [CCAMP] rwa wson framework: multi-degree ROADM >>>> >>>> Hi Young, >>>> >>>> Actually, I think the figure you propose is a bit confusing for a=20 >>>> couple of >>>> reasons: >>>> >>>> 1) It only depicts either ingress or egress for the four=20 >>>> =20 >> directions=20 >> =20 >>>> while in practice links are typically bidirectional. (The same is=20 >>>> true for the >>>> degree-2 ROADM example in the draft but there it is less=20 >>>> =20 >> confusing.) >> =20 >>>> 2) The way the ports are numbered, to me it looks like=20 >>>> =20 >> Ingress 1(2)=20 >> =20 >>>> and Egress 1(2) are associated to the same direction which=20 >>>> =20 >> means that=20 >> =20 >>>> to me it looks more like a degree-2 ROADM. >>>> >>>> I think it would be clearer if you made all ports in the figures=20 >>>> bidirectional. >>>> >>>> Regards, >>>> Jonas >>>> >>>> =20 >>>> =20 >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>>>> Behalf Of Young Lee >>>>> Sent: den 18 september 2009 21:57 >>>>> To: 'Giovanni Martinelli' >>>>> Cc: ccamp@ietf.org >>>>> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >>>>> >>>>> Hi Giovanni, >>>>> We have added 4-degree ROADM figure and connectivity=20 >>>>> =20 >> matrix per your=20 >> =20 >>>>> suggestion in the draft. Below is tentative text we have added in=20 >>>>> Section 3.3.1. I hope this would satisfy your request. >>>>> Thanks. >>>>> Young >>>>> ---------------------------------------------------------------- >>>>> >>>>> Ingress 1 +---------------+ +---------------+ Egress 1=20 >>>>> ----> | | -->| |---->=20 >>>>> Ingress 2 | | | | Egress 2 >>>>> ----> | | -->| |----> =20 >>>>> +---------------+ +---------------+ >>>>> | | | | | | O O O O O O >>>>> | | | | | | | | | | | | >>>>> O O O O O O | | | | | | >>>>> E3 E4 E5 E6 E7 E8 I3 I4 I5 I6 I7 I8 >>>>> Triburary Side Drop Add >>>>> Figure 2 Degree-4 ROADM >>>>> >>>>> For the ROADM of Figure 2 the switched connectivity matrix can be=20 >>>>> expressed as follows. Note that this ROADM is based on per port=20 >>>>> add/drop. >>>>> Ingress Egress Port >>>>> Port #1 #2 #3 #4 #5 #6 #7 #8 >>>>> -------------- >>>>> #1: 1 1 0 0 0 1 1 1 >>>>> #2 1 1 1 1 1 0 0 0 >>>>> A =3D #3 0 1 0 0 0 0 0 0 >>>>> #4 0 1 0 0 0 0 0 0 >>>>> #5 0 1 0 0 0 0 0 0 >>>>> #6 1 0 0 0 0 0 0 0 #7 =20 >>>>> =20 >> 1 0 =20 >> =20 >>>>> 0 0 0 0 0 0 #8 1 0 0 0 0 0 0 0 >>>>> =20 >>>>> Where egress ports 3-5 are drop ports from Ingress 2 and egress=20 >>>>> ports 6-8 are drop ports from Ingress 1 and ingress ports 3-5 are=20 >>>>> add ports to Egress 2, ingress ports 6-8 are add ports to=20 >>>>> =20 >> Egress 1. >> =20 >>>>> -----Original Message----- >>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>>>> Behalf Of Giovanni Martinelli >>>>> Sent: Thursday, September 17, 2009 2:59 AM >>>>> To: Greg Bernstein >>>>> Cc: ccamp@ietf.org >>>>> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >>>>> >>>>> Hi Greg, >>>>> >>>>> Greg Bernstein wrote: >>>>> =20 >>>>> =20 >>>>>> Hi Giovanni, in the example given in section 5 (thanks=20 >>>>>> =20 >> to Dirk) we=20 >> =20 >>>>>> have multi-degree ROADMs. In section 3.3.1 we do mention =20 >>>>>> =20 >>>>> higher degree =20 >>>>> =20 >>>>>> ROADMs but refer readers to another draft. Hmm, maybe we =20 >>>>>> =20 >>>>> should also =20 >>>>> =20 >>>>>> point them to section 5. >>>>>> =20 >>>>>> =20 >>>>> um well Section 5 provide more a high level overview and=20 >>>>> =20 >> the scope=20 >> =20 >>>>> is a bit different while the other reference at the end still=20 >>>>> contain 2 degree roadm (unless I'm missing something) >>>>> >>>>> This section was providing details about how a roadm is presented=20 >>>>> and the respective connectivity matrix (while in other=20 >>>>> =20 >> examples the=20 >> =20 >>>>> connectivity matrix only shows what is important for the example=20 >>>>> itself). >>>>> >>>>> To me this is important to show how exactly every roadm can be=20 >>>>> represented (and I guess generalizing from 4 to n will be clearer=20 >>>>> than doing from 2 to n degree) and the size of the=20 >>>>> =20 >> matrix (then how=20 >> =20 >>>>> is sparse is another topic). >>>>> >>>>> >>>>> =20 >>>>> =20 >>>>>> While I don't mind adding another picture, I think the =20 >>>>>> =20 >>>>> chairs will be =20 >>>>> =20 >>>>>> more interested in us reducing the length of the document than=20 >>>>>> expanding it ;-) . >>>>>> >>>>>> =20 >>>>>> =20 >>>>> well hope it's not the main criteria (we can always shot for the=20 >>>>> longest >>>>> RFC) ;-) >>>>> >>>>> Cheers >>>>> G >>>>> >>>>> =20 >>>>> =20 >>>>>> Cheers >>>>>> >>>>>> Greg >>>>>> >>>>>> Giovanni Martinelli wrote: >>>>>> =20 >>>>>> =20 >>>>>>> Hi Greg & WSONers, >>>>>>> >>>>>>> well, I saw you just suggest a last call request but I=20 >>>>>>> =20 >> was =20 >> =20 >>>>> wondering =20 >>>>> =20 >>>>>>> about representing a more general case of ROAM in section 3.3.1 >>>>>>> >>>>>>> The ID currently represent a 2 degree ROADM but looks=20 >>>>>>> =20 >> to me a very=20 >> =20 >>>>>>> specific case so I'm asking if it's ok adding a 4=20 >>>>>>> =20 >> degree =20 >> =20 >>>>> ROADM as well. >>>>> =20 >>>>> =20 >>>>>>> Here just a rough idea starting from your current picture >>>>>>> >>>>>>> +---------------------+ Line =20 >>>>>>> =20 >>>>> side-1 ingress >>>>> =20 >>>>> =20 >>>>>>> --->| |---> Line side-2 egress >>>>>>> Line side-1 egress <---| |<--- =20 >>>>>>> =20 >> Line side-2=20 >> =20 >>>>>>> ingress >>>>>>> | ROADM | >>>>>>> Line side-3 ingress --->| |---> =20 >>>>>>> =20 >> Line =20 >> =20 >>>>> side-4 egress >>>>> =20 >>>>> =20 >>>>>>> Line side-3 egress <---| |<--- =20 >>>>>>> =20 >> Line side-4=20 >> =20 >>>>>>> ingress >>>>>>> | | >>>>>>> +---------------------+ >>>>>>> | | | | o o o o >>>>>>> | | | | | | | | >>>>>>> O O O O | | | | >>>>>>> Tributary Side: Drop (egress) Add (ingress) >>>>>>> >>>>>>> >>>>>>> 1/ line sides likely have ingress and egress. >>>>>>> >>>>>>> >>>>>>> 2/ Tributaries might be associated to sides but I would =20 >>>>>>> =20 >>>>> consider that =20 >>>>> =20 >>>>>>> as switching constrain. >>>>>>> >>>>>>> Does the switching matrix will apply in the same way, =20 >>>>>>> =20 >>>>> become an 8x8 =20 >>>>> =20 >>>>>>> right?. >>>>>>> >>>>>>> Any thoughts about? >>>>>>> >>>>>>> >>>>>>> Cheers >>>>>>> G >>>>>>> _______________________________________________ >>>>>>> CCAMP mailing list >>>>>>> CCAMP@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>> >>>>>>> =20 >>>>>>> =20 >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> _______________________________________________ >>>>> CCAMP mailing list >>>>> CCAMP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>> >>>>> >>>>> =20 >>>>> =20 >>>> >>>> =20 >>>> =20 >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> >>> =20 >> -- >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >> >> >> >> >> =20 > > > =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------000107050906070005020504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks Jonas, this example seems good in that it illustrates:
(a) Bi-directional ROADM
(b) Higher degree ROADM
(c) A more complicated connectivity matrix due to the per port type of add/drop connectivity.

Although the number of add/drop ports is low we could comment in the text that this is for simplicity in drawing the figure.
I was thinking of then adding this example to section 3.3.1 after the simple example of the unidirectional 2-degree ROADM.
How does that sound to you?  Giovanni, Young, and others, does that sound good to you?

Best Regards

Greg

Jonas Mårtensson wrote: 
Hi,

Greg, as you say, the encoding draft specifies an efficient way to represent the connectivity of a switching node. However, the current (uni-directional) examples in section 3.1.1 of the framework draft do not illustrate one reason why the encoding draft representation is efficient, which is that the connectivity constraints for typical ROADM designs are "bi-directional", i.e. if ingress port X can (or can't) be connected to egress port Y, typically ingress port Y can (or can't) be connected to egress port X, assuming the numbering is done in such a way that ingress X and egress X correspond to the same line side direction or the same add/drop port. This makes the connectivity matrix symmetrical (which can be taken advantage of by setting the directionality bits of the link sets in the encoding draft representation to bidirectional). Borrowing Giovanni's (slightly modified) proposed 4-degree example with one (potentially multi-channel) add/drop per line side port to illustra
te : 


                             +------------------------+  
Line side-1 ingress (I1) --->|                        |--->  Line side-2 egress (E2)
Line side-1 egress (E1)  <---|                        |<---  Line side-2 ingress (I2)
                             |        ROADM           |
Line side-3 ingress (I3) --->|                        |--->  Line side-4 egress (E4)
Line side-3 egress (E3)  <---|                        |<---  Line side-4 ingress (I4)
                             |                        |
                             +------------------------+
                              | O    | O    | O    | O
                              | |    | |    | |    | |
                              O |    O |    O |    O |
         Tributary Side:     E5 I5  E6 I6  E7 I7  E8 I8


Corresponding 8x8 sparse and symmetrical connectivity matrix:

	Ingress	Egress Port
	Port		E1 E2	E3 E4	E5 E6 E7 E8
			--------------
		I1	0  1 	1  1  0  1 	0  0
		I2	1  0  1  1  0  0 	1  0
   	A =	I3	1  1 	0  1 	1  0  0  0
		I4	1  1 	1  0 	0  0	0  1
		I5	0  0 	1  0 	0  0  0  0
            I6    1  0  0  0  0  0  0  0 
            I7   	0  1  0  0  0  0  0  0 
            I8    0  0  0  1  0  0  0  0

where I5/E5 are add/drop ports to/from line side-3, I6/E6 are add/drop ports to/from line side-1, I7/E7 are add/drop ports to/from line side-2 and I8/E8 are add/drop ports to/from line side-4. Note that diagonal elements are zero since I assume that loopback is not supported. If ports support loopback, diagonal elements would be one.

Do you think such an example would be useful?

Regards,
Jonas


  
-----Original Message-----
From: Greg Bernstein [mailto:gregb@grotto-networking.com] 
Sent: den 21 september 2009 20:12
To: Giovanni Martinelli
Cc: Young Lee; ccamp@ietf.org; Jonas Mårtensson
Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM

Hi folks, for the framework document we currently have an 
example of a 2-Degree unidirectional ROADM. Which represents 
about the simplest asymmetric switching  system we can show.  
The  general connectivity matrix  formulation is at its core 
is unidirectional, i.e.,  deals with the potential 
connectivity of each ingress and egress pair separately to be 
generally applicable. Note that the encoding draft hits the 
issue of how to represent this stuff compactly on the wire.

Note the size of the  matrix is in terms of (# of ingress 
ports) X  (# of egress ports) and don't forget to include add 
and drop ports. The interesting feature of higher degree 
ROADMs is that two ROADMs of the same "degree"  may have very 
different connectivity properties. For example in 
architectures based on add/drop per node versus add/drop per 
fiber. In your 4-degree example Giovanni the number of add 
and drop ports seemed rather small and seems to make it hard 
to illustrate the difference between a "drop per node" and a 
"drop per fiber" style architecture.

What aspects do you want to see illustrated most in this 
section of the draft? I'm thinking of adding some  text to 
address the general case a bit more since the draft can refer 
to a published paper (in JOCN) that furnishes a significant 
number of examples of higher order and bidirectional ROADMs.

Cheers

Greg

Giovanni Martinelli wrote:
    
Hi,

Young Lee wrote:
      
Hi Jonas,

Yes you are right. Due to the ASCII limitation, the 
        
figures for both 
    
2-degree and 4-degree ROADM are shown only for one direction.
        
although ascii art difficult, I got the issue in 
      
understanding where 
    
bi-directionality apply as well. That's why I was trying to get all 
directions in one picture (but not sure the result was ok).

      
For your
question (2), we have added a note that this ROADM is based on per 
port add/drop (which is hard to show with ASCII) which 
        
means Ingress 
    
1(2) and Egress 1(2) are associated to the different directions.
  
        
One more clarification on the topic: the fact that we represent 
connectivity matrix done by (ingress x egress) it means we have a 
matrix for each directions?

thx
G

      
Hope this clarifies your question... Thanks.
Regards,
Young

-----Original Message-----
From: Jonas Mårtensson [mailto:Jonas.Martensson@acreo.se] Sent: 
Monday, September 21, 2009 10:21 AM
To: Young Lee; 'Giovanni Martinelli'
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] rwa wson framework: multi-degree ROADM

Hi Young,

Actually, I think the figure you propose is a bit confusing for a 
couple of
reasons:

1) It only depicts either ingress or egress for the four 
        
directions 
    
while in practice links are typically bidirectional. (The same is 
true for the
degree-2 ROADM example in the draft but there it is less 
        
confusing.)
    
2) The way the ports are numbered, to me it looks like 
        
Ingress 1(2) 
    
and Egress 1(2) are associated to the same direction which 
        
means that 
    
to me it looks more like a degree-2 ROADM.

I think it would be clearer if you made all ports in the figures 
bidirectional.

Regards,
Jonas

 
        
-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On 
Behalf Of Young Lee
Sent: den 18 september 2009 21:57
To: 'Giovanni Martinelli'
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM

Hi Giovanni,
We have added 4-degree ROADM figure and connectivity 
          
matrix per your 
    
suggestion in the draft. Below is tentative text we have added in 
Section 3.3.1. I hope this would satisfy your request.
Thanks.
Young
----------------------------------------------------------------

Ingress 1  +---------------+    +---------------+    Egress 1 
               ----> |               | -->|               |----> 
Ingress 2  |               |    |               |    Egress 2
     ----> |               | -->|              |---->            
+---------------+    +---------------+
             | | |    | | |      O O O     O O O
             | | |    | | |      | | |     | | |
             O O O    O O O      | | |     | | |
              E3 E4 E5  E6 E7 E8   I3 I4 I5  I6 I7 I8
               Triburary Side     Drop                 Add
Figure 2    Degree-4 ROADM

For the ROADM of Figure 2 the switched connectivity matrix can be 
expressed as follows. Note that this ROADM is based on per port 
add/drop.
    Ingress    Egress Port
    Port        #1 #2    #3 #4    #5 #6 #7 #8
            --------------
        #1:    1  1     0  0  0  1     1  1
        #2    1  1  1  1  1  0     0  0
       A =    #3    0  1     0  0     0  0  0  0
        #4    0  1     0  0     0  0    0  0
        #5    0  1     0  0     0  0  0  0
            #6    1  0  0  0  0  0  0  0             #7   
          
    1  0  
    
0  0  0  0  0  0             #8    1  0  0  0  0  0  0  0
  
Where egress ports 3-5 are drop ports from Ingress 2 and egress 
ports 6-8 are drop ports from Ingress 1 and ingress ports 3-5 are 
add ports to Egress 2, ingress ports 6-8 are add ports to 
          
Egress 1.
    
-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On 
Behalf Of Giovanni Martinelli
Sent: Thursday, September 17, 2009 2:59 AM
To: Greg Bernstein
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM

Hi Greg,

Greg Bernstein wrote:
   
          
Hi Giovanni, in the example given in section 5 (thanks 
            
to Dirk) we 
    
have multi-degree ROADMs. In section 3.3.1 we do mention       
            
higher degree    
          
ROADMs but refer readers to another draft. Hmm, maybe we       
            
should also    
          
point them to section 5.
      
            
um well Section 5 provide more a high level overview and 
          
the scope 
    
is a bit different while the other reference at the end still 
contain 2 degree roadm (unless I'm missing something)

This section was providing details about how a roadm is presented 
and the respective connectivity matrix (while in other 
          
examples the 
    
connectivity matrix only shows what is important for the example 
itself).

To me this is important to show how exactly every roadm can be 
represented (and I guess generalizing from 4 to n will be clearer 
than doing from 2 to n degree) and the size of  the 
          
matrix (then how 
    
is sparse is another topic).


   
          
While I don't mind adding another picture, I think the       
            
chairs will be    
          
more interested in us reducing the length of the document than 
expanding it ;-) .

      
            
well hope it's not the main criteria (we can always shot for the 
longest
RFC) ;-)

Cheers
G

   
          
Cheers

Greg

Giovanni Martinelli wrote:
     
            
Hi Greg & WSONers,

well, I saw you just suggest a last call request but I 
              
was         
    
wondering    
          
about representing a more general case of ROAM in section 3.3.1

The ID currently represent a 2 degree ROADM but looks 
              
to me a very 
    
specific case so I'm asking if it's ok adding a 4 
              
degree         
    
ROADM as well.
   
          
Here just a rough idea starting from your current picture

                        +---------------------+  Line         
              
side-1 ingress
   
          
--->|                     |--->  Line side-2 egress
Line side-1 egress   <---|                     |<---  
              
Line side-2 
    
ingress
                        |        ROADM        |
Line side-3 ingress  --->|                     |--->  
              
Line         
    
side-4 egress
   
          
Line side-3 egress   <---|                     |<---  
              
Line side-4 
    
ingress
                        |                     |
                        +---------------------+
                           | | | |  o o o o
                           | | | |  | | | |
                           O O O O  | | | |
     Tributary Side:   Drop (egress)  Add (ingress)


1/ line sides likely have ingress and egress.


2/ Tributaries might be associated to sides but I would         
              
consider that    
          
as  switching constrain.

Does the switching matrix will apply in the same way,         
              
become an 8x8    
          
right?.

Any thoughts about?


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

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


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


    
          

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

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




    


  

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------000107050906070005020504-- From giomarti@cisco.com Tue Sep 22 08:13:29 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 493883A6A96 for ; Tue, 22 Sep 2009 08:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.58 X-Spam-Level: X-Spam-Status: No, score=-10.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 3ryLvwBEk8wx for ; Tue, 22 Sep 2009 08:13:27 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DC46F28C0D7 for ; Tue, 22 Sep 2009 08:13:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQAAFuGuEqQ/uCLe2dsb2JhbACacwEBFiQGpFWITwEyCY9IBYJHgVQ X-IronPort-AV: E=Sophos;i="4.44,432,1249257600"; d="scan'208";a="49973191" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Sep 2009 15:14:29 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8MFETk9029346; Tue, 22 Sep 2009 17:14:29 +0200 Received: from [10.61.96.242] (dhcp-10-61-96-242.cisco.com [10.61.96.242]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8MFER7o009679; Tue, 22 Sep 2009 15:14:28 GMT Message-ID: <4AB8E9D3.8090803@cisco.com> Date: Tue, 22 Sep 2009 17:14:27 +0200 From: Giovanni Martinelli User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Greg Bernstein References: <4AAFB210.8000802@cisco.com> <4AAFB6FF.2060301@grotto-networking.com> <4AB1EC48.2050407@cisco.com> <002001ca389a$1e7eb5a0$4c0c7c0a@china.huawei.com> <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BA4@acreoexc01.ad.acreo.se> <001d01ca3ad4$2c1127c0$4c0c7c0a@china.huawei.com> <4AB7A915.9000903@cisco.com> <4AB7C1F7.9040204@grotto-networking.com> <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BBB@acreoexc01.ad.acreo.se> <4AB8E466.3020509@grotto-networking.com> In-Reply-To: <4AB8E466.3020509@grotto-networking.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16377; t=1253632469; x=1254496469; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=giomarti@cisco.com; z=From:=20Giovanni=20Martinelli=20 |Subject:=20Re=3A=20[CCAMP]=20rwa=20wson=20framework=3A=20m ulti-degree=20ROADM |Sender:=20; bh=GZ9cg7xk9P4BCjhwd6+3ZcDZ3ZvSpAgNGpS9YZ57bHQ=; b=Cm9wddW2kNCdLjxUo6LLF8IWQE6QmakaLOwTA7j+F5cKEhMZN5lzw1SWeT hKVzb1XIEO5kSlU7Zthtx3Ais0pg+ALwlmazRxnlrOQumBK7Q6aS0C8WaOEG +gkQzH/iuF; Authentication-Results: ams-dkim-2; header.From=giomarti@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM 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, 22 Sep 2009 15:13:29 -0000 Greg Bernstein wrote: > Thanks Jonas, this example seems good in that it illustrates: > (a) Bi-directional ROADM > (b) Higher degree ROADM > (c) A more complicated connectivity matrix due to the per port type of = > add/drop connectivity. > > Although the number of add/drop ports is low we could comment in the=20 > text that this is for simplicity in drawing the figure. > I was thinking of then adding this example to section 3.3.1 after the=20 > simple example of the unidirectional 2-degree ROADM. > How does that sound to you? Giovanni, Young, and others, does that=20 > sound good to you? perfect to me! thx G > > Best Regards > > Greg > > Jonas M=E5rtensson wrote: >> Hi, >> >> Greg, as you say, the encoding draft specifies an efficient way to rep= resent the connectivity of a switching node. However, the current (uni-di= rectional) examples in section 3.1.1 of the framework draft do not illust= rate one reason why the encoding draft representation is efficient, which= is that the connectivity constraints for typical ROADM designs are "bi-d= irectional", i.e. if ingress port X can (or can't) be connected to egress= port Y, typically ingress port Y can (or can't) be connected to egress p= ort X, assuming the numbering is done in such a way that ingress X and eg= ress X correspond to the same line side direction or the same add/drop po= rt. This makes the connectivity matrix symmetrical (which can be taken ad= vantage of by setting the directionality bits of the link sets in the enc= oding draft representation to bidirectional). Borrowing Giovanni's (sligh= tly modified) proposed 4-degree example with one (potentially multi-chann= el) add/drop per line side port to illustra >> te :=20 >> >> >> +------------------------+ =20 >> Line side-1 ingress (I1) --->| |---> Line side= -2 egress (E2) >> Line side-1 egress (E1) <---| |<--- Line side= -2 ingress (I2) >> | ROADM | >> Line side-3 ingress (I3) --->| |---> Line side= -4 egress (E4) >> Line side-3 egress (E3) <---| |<--- Line side= -4 ingress (I4) >> | | >> +------------------------+ >> | O | O | O | O >> | | | | | | | | >> O | O | O | O | >> Tributary Side: E5 I5 E6 I6 E7 I7 E8 I8 >> >> >> Corresponding 8x8 sparse and symmetrical connectivity matrix: >> >> Ingress Egress Port >> Port E1 E2 E3 E4 E5 E6 E7 E8 >> -------------- >> I1 0 1 1 1 0 1 0 0 >> I2 1 0 1 1 0 0 1 0 >> A =3D I3 1 1 0 1 1 0 0 0 >> I4 1 1 1 0 0 0 0 1 >> I5 0 0 1 0 0 0 0 0 >> I6 1 0 0 0 0 0 0 0=20 >> I7 0 1 0 0 0 0 0 0=20 >> I8 0 0 0 1 0 0 0 0 >> >> where I5/E5 are add/drop ports to/from line side-3, I6/E6 are add/drop= ports to/from line side-1, I7/E7 are add/drop ports to/from line side-2 = and I8/E8 are add/drop ports to/from line side-4. Note that diagonal elem= ents are zero since I assume that loopback is not supported. If ports sup= port loopback, diagonal elements would be one. >> >> Do you think such an example would be useful? >> >> Regards, >> Jonas >> >> >> =20 >>> -----Original Message----- >>> From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 >>> Sent: den 21 september 2009 20:12 >>> To: Giovanni Martinelli >>> Cc: Young Lee; ccamp@ietf.org; Jonas M=E5rtensson >>> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >>> >>> Hi folks, for the framework document we currently have an=20 >>> example of a 2-Degree unidirectional ROADM. Which represents=20 >>> about the simplest asymmetric switching system we can show. =20 >>> The general connectivity matrix formulation is at its core=20 >>> is unidirectional, i.e., deals with the potential=20 >>> connectivity of each ingress and egress pair separately to be=20 >>> generally applicable. Note that the encoding draft hits the=20 >>> issue of how to represent this stuff compactly on the wire. >>> >>> Note the size of the matrix is in terms of (# of ingress=20 >>> ports) X (# of egress ports) and don't forget to include add=20 >>> and drop ports. The interesting feature of higher degree=20 >>> ROADMs is that two ROADMs of the same "degree" may have very=20 >>> different connectivity properties. For example in=20 >>> architectures based on add/drop per node versus add/drop per=20 >>> fiber. In your 4-degree example Giovanni the number of add=20 >>> and drop ports seemed rather small and seems to make it hard=20 >>> to illustrate the difference between a "drop per node" and a=20 >>> "drop per fiber" style architecture. >>> >>> What aspects do you want to see illustrated most in this=20 >>> section of the draft? I'm thinking of adding some text to=20 >>> address the general case a bit more since the draft can refer=20 >>> to a published paper (in JOCN) that furnishes a significant=20 >>> number of examples of higher order and bidirectional ROADMs. >>> >>> Cheers >>> >>> Greg >>> >>> Giovanni Martinelli wrote: >>> =20 >>>> Hi, >>>> >>>> Young Lee wrote: >>>> =20 >>>>> Hi Jonas, >>>>> >>>>> Yes you are right. Due to the ASCII limitation, the=20 >>>>> =20 >>> figures for both=20 >>> =20 >>>>> 2-degree and 4-degree ROADM are shown only for one direction. >>>>> =20 >>>> although ascii art difficult, I got the issue in=20 >>>> =20 >>> understanding where=20 >>> =20 >>>> bi-directionality apply as well. That's why I was trying to get all = >>>> directions in one picture (but not sure the result was ok). >>>> >>>> =20 >>>>> For your >>>>> question (2), we have added a note that this ROADM is based on per = >>>>> port add/drop (which is hard to show with ASCII) which=20 >>>>> =20 >>> means Ingress=20 >>> =20 >>>>> 1(2) and Egress 1(2) are associated to the different directions. >>>>> =20 >>>>> =20 >>>> One more clarification on the topic: the fact that we represent=20 >>>> connectivity matrix done by (ingress x egress) it means we have a=20 >>>> matrix for each directions? >>>> >>>> thx >>>> G >>>> >>>> =20 >>>>> Hope this clarifies your question... Thanks. >>>>> Regards, >>>>> Young >>>>> >>>>> -----Original Message----- >>>>> From: Jonas M=E5rtensson [mailto:Jonas.Martensson@acreo.se] Sent:=20 >>>>> Monday, September 21, 2009 10:21 AM >>>>> To: Young Lee; 'Giovanni Martinelli' >>>>> Cc: ccamp@ietf.org >>>>> Subject: RE: [CCAMP] rwa wson framework: multi-degree ROADM >>>>> >>>>> Hi Young, >>>>> >>>>> Actually, I think the figure you propose is a bit confusing for a=20 >>>>> couple of >>>>> reasons: >>>>> >>>>> 1) It only depicts either ingress or egress for the four=20 >>>>> =20 >>> directions=20 >>> =20 >>>>> while in practice links are typically bidirectional. (The same is=20 >>>>> true for the >>>>> degree-2 ROADM example in the draft but there it is less=20 >>>>> =20 >>> confusing.) >>> =20 >>>>> 2) The way the ports are numbered, to me it looks like=20 >>>>> =20 >>> Ingress 1(2)=20 >>> =20 >>>>> and Egress 1(2) are associated to the same direction which=20 >>>>> =20 >>> means that=20 >>> =20 >>>>> to me it looks more like a degree-2 ROADM. >>>>> >>>>> I think it would be clearer if you made all ports in the figures=20 >>>>> bidirectional. >>>>> >>>>> Regards, >>>>> Jonas >>>>> >>>>> =20 >>>>> =20 >>>>>> -----Original Message----- >>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>>>>> Behalf Of Young Lee >>>>>> Sent: den 18 september 2009 21:57 >>>>>> To: 'Giovanni Martinelli' >>>>>> Cc: ccamp@ietf.org >>>>>> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >>>>>> >>>>>> Hi Giovanni, >>>>>> We have added 4-degree ROADM figure and connectivity=20 >>>>>> =20 >>> matrix per your=20 >>> =20 >>>>>> suggestion in the draft. Below is tentative text we have added in = >>>>>> Section 3.3.1. I hope this would satisfy your request. >>>>>> Thanks. >>>>>> Young >>>>>> ---------------------------------------------------------------- >>>>>> >>>>>> Ingress 1 +---------------+ +---------------+ Egress 1=20 >>>>>> ----> | | -->| |---->=20 >>>>>> Ingress 2 | | | | Egress 2 >>>>>> ----> | | -->| |----> =20 >>>>>> +---------------+ +---------------+ >>>>>> | | | | | | O O O O O O >>>>>> | | | | | | | | | | | | >>>>>> O O O O O O | | | | | | >>>>>> E3 E4 E5 E6 E7 E8 I3 I4 I5 I6 I7 I8 >>>>>> Triburary Side Drop Add >>>>>> Figure 2 Degree-4 ROADM >>>>>> >>>>>> For the ROADM of Figure 2 the switched connectivity matrix can be = >>>>>> expressed as follows. Note that this ROADM is based on per port=20 >>>>>> add/drop. >>>>>> Ingress Egress Port >>>>>> Port #1 #2 #3 #4 #5 #6 #7 #8 >>>>>> -------------- >>>>>> #1: 1 1 0 0 0 1 1 1 >>>>>> #2 1 1 1 1 1 0 0 0 >>>>>> A =3D #3 0 1 0 0 0 0 0 0 >>>>>> #4 0 1 0 0 0 0 0 0 >>>>>> #5 0 1 0 0 0 0 0 0 >>>>>> #6 1 0 0 0 0 0 0 0 #7 =20 >>>>>> =20 >>> 1 0 =20 >>> =20 >>>>>> 0 0 0 0 0 0 #8 1 0 0 0 0 0 0 0 >>>>>> =20 >>>>>> Where egress ports 3-5 are drop ports from Ingress 2 and egress=20 >>>>>> ports 6-8 are drop ports from Ingress 1 and ingress ports 3-5 are = >>>>>> add ports to Egress 2, ingress ports 6-8 are add ports to=20 >>>>>> =20 >>> Egress 1. >>> =20 >>>>>> -----Original Message----- >>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 >>>>>> Behalf Of Giovanni Martinelli >>>>>> Sent: Thursday, September 17, 2009 2:59 AM >>>>>> To: Greg Bernstein >>>>>> Cc: ccamp@ietf.org >>>>>> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM >>>>>> >>>>>> Hi Greg, >>>>>> >>>>>> Greg Bernstein wrote: >>>>>> =20 >>>>>> =20 >>>>>>> Hi Giovanni, in the example given in section 5 (thanks=20 >>>>>>> =20 >>> to Dirk) we=20 >>> =20 >>>>>>> have multi-degree ROADMs. In section 3.3.1 we do mention =20 >>>>>>> =20 >>>>>> higher degree =20 >>>>>> =20 >>>>>>> ROADMs but refer readers to another draft. Hmm, maybe we =20 >>>>>>> =20 >>>>>> should also =20 >>>>>> =20 >>>>>>> point them to section 5. >>>>>>> =20 >>>>>>> =20 >>>>>> um well Section 5 provide more a high level overview and=20 >>>>>> =20 >>> the scope=20 >>> =20 >>>>>> is a bit different while the other reference at the end still=20 >>>>>> contain 2 degree roadm (unless I'm missing something) >>>>>> >>>>>> This section was providing details about how a roadm is presented = >>>>>> and the respective connectivity matrix (while in other=20 >>>>>> =20 >>> examples the=20 >>> =20 >>>>>> connectivity matrix only shows what is important for the example=20 >>>>>> itself). >>>>>> >>>>>> To me this is important to show how exactly every roadm can be=20 >>>>>> represented (and I guess generalizing from 4 to n will be clearer = >>>>>> than doing from 2 to n degree) and the size of the=20 >>>>>> =20 >>> matrix (then how=20 >>> =20 >>>>>> is sparse is another topic). >>>>>> >>>>>> >>>>>> =20 >>>>>> =20 >>>>>>> While I don't mind adding another picture, I think the =20 >>>>>>> =20 >>>>>> chairs will be =20 >>>>>> =20 >>>>>>> more interested in us reducing the length of the document than=20 >>>>>>> expanding it ;-) . >>>>>>> >>>>>>> =20 >>>>>>> =20 >>>>>> well hope it's not the main criteria (we can always shot for the=20 >>>>>> longest >>>>>> RFC) ;-) >>>>>> >>>>>> Cheers >>>>>> G >>>>>> >>>>>> =20 >>>>>> =20 >>>>>>> Cheers >>>>>>> >>>>>>> Greg >>>>>>> >>>>>>> Giovanni Martinelli wrote: >>>>>>> =20 >>>>>>> =20 >>>>>>>> Hi Greg & WSONers, >>>>>>>> >>>>>>>> well, I saw you just suggest a last call request but I=20 >>>>>>>> =20 >>> was =20 >>> =20 >>>>>> wondering =20 >>>>>> =20 >>>>>>>> about representing a more general case of ROAM in section 3.3.1 >>>>>>>> >>>>>>>> The ID currently represent a 2 degree ROADM but looks=20 >>>>>>>> =20 >>> to me a very=20 >>> =20 >>>>>>>> specific case so I'm asking if it's ok adding a 4=20 >>>>>>>> =20 >>> degree =20 >>> =20 >>>>>> ROADM as well. >>>>>> =20 >>>>>> =20 >>>>>>>> Here just a rough idea starting from your current picture >>>>>>>> >>>>>>>> +---------------------+ Line =20 >>>>>>>> =20 >>>>>> side-1 ingress >>>>>> =20 >>>>>> =20 >>>>>>>> --->| |---> Line side-2 egress >>>>>>>> Line side-1 egress <---| |<--- =20 >>>>>>>> =20 >>> Line side-2=20 >>> =20 >>>>>>>> ingress >>>>>>>> | ROADM | >>>>>>>> Line side-3 ingress --->| |---> =20 >>>>>>>> =20 >>> Line =20 >>> =20 >>>>>> side-4 egress >>>>>> =20 >>>>>> =20 >>>>>>>> Line side-3 egress <---| |<--- =20 >>>>>>>> =20 >>> Line side-4=20 >>> =20 >>>>>>>> ingress >>>>>>>> | | >>>>>>>> +---------------------+ >>>>>>>> | | | | o o o o >>>>>>>> | | | | | | | | >>>>>>>> O O O O | | | | >>>>>>>> Tributary Side: Drop (egress) Add (ingress) >>>>>>>> >>>>>>>> >>>>>>>> 1/ line sides likely have ingress and egress. >>>>>>>> >>>>>>>> >>>>>>>> 2/ Tributaries might be associated to sides but I would = >>>>>>>> =20 >>>>>> consider that =20 >>>>>> =20 >>>>>>>> as switching constrain. >>>>>>>> >>>>>>>> Does the switching matrix will apply in the same way, =20 >>>>>>>> =20 >>>>>> become an 8x8 =20 >>>>>> =20 >>>>>>>> right?. >>>>>>>> >>>>>>>> Any thoughts about? >>>>>>>> >>>>>>>> >>>>>>>> Cheers >>>>>>>> G >>>>>>>> _______________________________________________ >>>>>>>> CCAMP mailing list >>>>>>>> CCAMP@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>>>> >>>>>>>> =20 >>>>>>>> =20 >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> CCAMP mailing list >>>>>> CCAMP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ccamp >>>>>> >>>>>> >>>>>> =20 >>>>>> =20 >>>>> =20 >>>>> =20 >>>> _______________________________________________ >>>> CCAMP mailing list >>>> CCAMP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ccamp >>>> >>>> =20 >>> -- >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>> Dr Greg Bernstein, Grotto Networking (510) 573-2237 >>> >>> >>> >>> >>> =20 >> >> >> =20 > > --=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > =20 From root@core3.amsl.com Tue Sep 22 08:30:03 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B9C343A68EF; Tue, 22 Sep 2009 08:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090922153002.B9C343A68EF@core3.amsl.com> Date: Tue, 22 Sep 2009 08:30:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-pc-spc-rsvpte-ext-04.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 15:30:03 -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-04.txt Pages : 19 Date : 2009-09-22 We would like to dedicate this work to our friend and colleague Dino Bramanti, who passed away at the early age of 38. Dino has been involved in this work since its beginning. In a transport network scenario, where Data Plane connections controlled either by GMPLS Control Plane (Soft Permanent Connections - SPC) or by 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. 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-spc-rsvpte-ext-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-pc-spc-rsvpte-ext-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-22082159.I-D@ietf.org> --NextPart-- From jonas.martensson@acreo.se Tue Sep 22 08:34:53 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C73B828C149 for ; Tue, 22 Sep 2009 08:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HELO_EQ_DK=1.009, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-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 ltYE2IeZNyUB for ; Tue, 22 Sep 2009 08:34:52 -0700 (PDT) Received: from dkcphmx24.softcom.dk (dkcphmx24.softcom.dk [194.192.15.188]) by core3.amsl.com (Postfix) with ESMTP id 31A1F28C12C for ; Tue, 22 Sep 2009 08:34:51 -0700 (PDT) Received: (qmail 19913 invoked by uid 74); 22 Sep 2009 15:35:53 -0000 Received: from mail.acreo.se (217.151.195.216) by dkcphmx24.softcom.dk (envelope-from ) with ESMTP. tag msg.1253633753.88803.6663 (Processed in 0.249882 secs); 22 Sep 2009 15:35:53 -0000 X-SoftScan-Status: clean X-Secure-TLS: Yes, message received through TLS by dkcphmx24.softcom.dk (RC4-MD5) Received: from mail.acreo.se (HELO mail.acreo.se) (217.151.195.216) by dkcphmx24.softcom.dk over TLS secured channel with (RC4-MD5 encrypted) ESMTPS; Tue, 22 Sep 2009 17:35:53 +0200 Received: from acreoexc01.ad.acreo.se ([10.4.148.12]) by acreoexc01.ad.acreo.se ([10.4.148.12]) with mapi; Tue, 22 Sep 2009 17:35:53 +0200 From: =?iso-8859-1?Q?Jonas_M=E5rtensson?= To: Giovanni Martinelli , Greg Bernstein Date: Tue, 22 Sep 2009 17:35:51 +0200 Thread-Topic: [CCAMP] rwa wson framework: multi-degree ROADM Thread-Index: Aco7l2g/6yajUgcSSi+ip372wETFkwAAtlXg Message-ID: <1EC35EEAF3A9FA439C7D6AE45BF43787017499974C77@acreoexc01.ad.acreo.se> References: <4AAFB210.8000802@cisco.com> <4AAFB6FF.2060301@grotto-networking.com> <4AB1EC48.2050407@cisco.com> <002001ca389a$1e7eb5a0$4c0c7c0a@china.huawei.com> <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BA4@acreoexc01.ad.acreo.se> <001d01ca3ad4$2c1127c0$4c0c7c0a@china.huawei.com> <4AB7A915.9000903@cisco.com> <4AB7C1F7.9040204@grotto-networking.com> <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BBB@acreoexc01.ad.acreo.se> <4AB8E466.3020509@grotto-networking.com> <4AB8E9D3.8090803@cisco.com> In-Reply-To: <4AB8E9D3.8090803@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM 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, 22 Sep 2009 15:34:53 -0000 Sounds good to me too. Cheers, Jonas > -----Original Message----- > From: Giovanni Martinelli [mailto:giomarti@cisco.com] > Sent: den 22 september 2009 17:14 > To: Greg Bernstein > Cc: Jonas M=E5rtensson; Young Lee; ccamp@ietf.org > Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM > > > > Greg Bernstein wrote: > > Thanks Jonas, this example seems good in that it illustrates: > > (a) Bi-directional ROADM > > (b) Higher degree ROADM > > (c) A more complicated connectivity matrix due to the per > port type of > > add/drop connectivity. > > > > Although the number of add/drop ports is low we could > comment in the > > text that this is for simplicity in drawing the figure. > > I was thinking of then adding this example to section 3.3.1 > after the > > simple example of the unidirectional 2-degree ROADM. > > How does that sound to you? Giovanni, Young, and others, does that > > sound good to you? > perfect to me! > > thx > G > > > > Best Regards > > > > Greg > > > > Jonas M=E5rtensson wrote: > >> Hi, > >> > >> Greg, as you say, the encoding draft specifies an efficient way to > >> represent the connectivity of a switching node. However, > the current (uni-directional) examples in section 3.1.1 of > the framework draft do not illustrate one reason why the > encoding draft representation is efficient, which is that the > connectivity constraints for typical ROADM designs are > "bi-directional", i.e. if ingress port X can (or can't) be > connected to egress port Y, typically ingress port Y can (or > can't) be connected to egress port X, assuming the numbering > is done in such a way that ingress X and egress X correspond > to the same line side direction or the same add/drop port. > This makes the connectivity matrix symmetrical (which can be > taken advantage of by setting the directionality bits of the > link sets in the encoding draft representation to > bidirectional). Borrowing Giovanni's (slightly modified) > proposed 4-degree example with one (potentially > multi-channel) add/drop per line side port to illustra te : > >> > >> > >> +------------------------+ > >> Line side-1 ingress (I1) --->| > |---> Line side-2 egress (E2) > >> Line side-1 egress (E1) <---| > |<--- Line side-2 ingress (I2) > >> | ROADM | > >> Line side-3 ingress (I3) --->| > |---> Line side-4 egress (E4) > >> Line side-3 egress (E3) <---| > |<--- Line side-4 ingress (I4) > >> | | > >> +------------------------+ > >> | O | O | O | O > >> | | | | | | | | > >> O | O | O | O | > >> Tributary Side: E5 I5 E6 I6 E7 I7 E8 I8 > >> > >> > >> Corresponding 8x8 sparse and symmetrical connectivity matrix: > >> > >> Ingress Egress Port > >> Port E1 E2 E3 E4 E5 E6 E7 E8 > >> -------------- > >> I1 0 1 1 1 0 1 0 0 > >> I2 1 0 1 1 0 0 1 0 > >> A =3D I3 1 1 0 1 1 0 0 0 > >> I4 1 1 1 0 0 0 0 1 > >> I5 0 0 1 0 0 0 0 0 > >> I6 1 0 0 0 0 0 0 0 > >> I7 0 1 0 0 0 0 0 0 > >> I8 0 0 0 1 0 0 0 0 > >> > >> where I5/E5 are add/drop ports to/from line side-3, I6/E6 > are add/drop ports to/from line side-1, I7/E7 are add/drop > ports to/from line side-2 and I8/E8 are add/drop ports > to/from line side-4. Note that diagonal elements are zero > since I assume that loopback is not supported. If ports > support loopback, diagonal elements would be one. > >> > >> Do you think such an example would be useful? > >> > >> Regards, > >> Jonas > >> > >> > >> > >>> -----Original Message----- > >>> From: Greg Bernstein [mailto:gregb@grotto-networking.com] > >>> Sent: den 21 september 2009 20:12 > >>> To: Giovanni Martinelli > >>> Cc: Young Lee; ccamp@ietf.org; Jonas M=E5rtensson > >>> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM > >>> > >>> Hi folks, for the framework document we currently have an > example of > >>> a 2-Degree unidirectional ROADM. Which represents about > the simplest > >>> asymmetric switching system we can show. > >>> The general connectivity matrix formulation is at its core is > >>> unidirectional, i.e., deals with the potential > connectivity of each > >>> ingress and egress pair separately to be generally > applicable. Note > >>> that the encoding draft hits the issue of how to represent this > >>> stuff compactly on the wire. > >>> > >>> Note the size of the matrix is in terms of (# of ingress > >>> ports) X (# of egress ports) and don't forget to include add and > >>> drop ports. The interesting feature of higher degree > ROADMs is that > >>> two ROADMs of the same "degree" may have very different > >>> connectivity properties. For example in architectures based on > >>> add/drop per node versus add/drop per fiber. In your 4-degree > >>> example Giovanni the number of add and drop ports seemed rather > >>> small and seems to make it hard to illustrate the > difference between > >>> a "drop per node" and a "drop per fiber" style architecture. > >>> > >>> What aspects do you want to see illustrated most in this > section of > >>> the draft? I'm thinking of adding some text to address > the general > >>> case a bit more since the draft can refer to a published > paper (in > >>> JOCN) that furnishes a significant number of examples of higher > >>> order and bidirectional ROADMs. > >>> > >>> Cheers > >>> > >>> Greg > >>> > >>> Giovanni Martinelli wrote: > >>> > >>>> Hi, > >>>> > >>>> Young Lee wrote: > >>>> > >>>>> Hi Jonas, > >>>>> > >>>>> Yes you are right. Due to the ASCII limitation, the > >>>>> > >>> figures for both > >>> > >>>>> 2-degree and 4-degree ROADM are shown only for one direction. > >>>>> > >>>> although ascii art difficult, I got the issue in > >>>> > >>> understanding where > >>> > >>>> bi-directionality apply as well. That's why I was trying > to get all > >>>> directions in one picture (but not sure the result was ok). > >>>> > >>>> > >>>>> For your > >>>>> question (2), we have added a note that this ROADM is > based on per > >>>>> port add/drop (which is hard to show with ASCII) which > >>>>> > >>> means Ingress > >>> > >>>>> 1(2) and Egress 1(2) are associated to the different directions. > >>>>> > >>>>> > >>>> One more clarification on the topic: the fact that we represent > >>>> connectivity matrix done by (ingress x egress) it means > we have a > >>>> matrix for each directions? > >>>> > >>>> thx > >>>> G > >>>> > >>>> > >>>>> Hope this clarifies your question... Thanks. > >>>>> Regards, > >>>>> Young > >>>>> > >>>>> -----Original Message----- > >>>>> From: Jonas M=E5rtensson [mailto:Jonas.Martensson@acreo.se] Sent: > >>>>> Monday, September 21, 2009 10:21 AM > >>>>> To: Young Lee; 'Giovanni Martinelli' > >>>>> Cc: ccamp@ietf.org > >>>>> Subject: RE: [CCAMP] rwa wson framework: multi-degree ROADM > >>>>> > >>>>> Hi Young, > >>>>> > >>>>> Actually, I think the figure you propose is a bit > confusing for a > >>>>> couple of > >>>>> reasons: > >>>>> > >>>>> 1) It only depicts either ingress or egress for the four > >>>>> > >>> directions > >>> > >>>>> while in practice links are typically bidirectional. > (The same is > >>>>> true for the > >>>>> degree-2 ROADM example in the draft but there it is less > >>>>> > >>> confusing.) > >>> > >>>>> 2) The way the ports are numbered, to me it looks like > >>>>> > >>> Ingress 1(2) > >>> > >>>>> and Egress 1(2) are associated to the same direction which > >>>>> > >>> means that > >>> > >>>>> to me it looks more like a degree-2 ROADM. > >>>>> > >>>>> I think it would be clearer if you made all ports in > the figures > >>>>> bidirectional. > >>>>> > >>>>> Regards, > >>>>> Jonas > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: ccamp-bounces@ietf.org > [mailto:ccamp-bounces@ietf.org] On > >>>>>> Behalf Of Young Lee > >>>>>> Sent: den 18 september 2009 21:57 > >>>>>> To: 'Giovanni Martinelli' > >>>>>> Cc: ccamp@ietf.org > >>>>>> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM > >>>>>> > >>>>>> Hi Giovanni, > >>>>>> We have added 4-degree ROADM figure and connectivity > >>>>>> > >>> matrix per your > >>> > >>>>>> suggestion in the draft. Below is tentative text we > have added in > >>>>>> Section 3.3.1. I hope this would satisfy your request. > >>>>>> Thanks. > >>>>>> Young > >>>>>> > ---------------------------------------------------------------- > >>>>>> > >>>>>> Ingress 1 +---------------+ +---------------+ Egress 1 > >>>>>> ----> | | -->| > |----> > >>>>>> Ingress 2 | | | | Egress 2 > >>>>>> ----> | | -->| |----> > > >>>>>> +---------------+ +---------------+ > >>>>>> | | | | | | O O O O O O > >>>>>> | | | | | | | | | | | | > >>>>>> O O O O O O | | | | | | > >>>>>> E3 E4 E5 E6 E7 E8 I3 I4 I5 I6 I7 I8 > >>>>>> Triburary Side Drop Add > >>>>>> Figure 2 Degree-4 ROADM > >>>>>> > >>>>>> For the ROADM of Figure 2 the switched connectivity > matrix can be > >>>>>> expressed as follows. Note that this ROADM is based on > per port > >>>>>> add/drop. > >>>>>> Ingress Egress Port > >>>>>> Port #1 #2 #3 #4 #5 #6 #7 #8 > >>>>>> -------------- > >>>>>> #1: 1 1 0 0 0 1 1 1 > >>>>>> #2 1 1 1 1 1 0 0 0 > >>>>>> A =3D #3 0 1 0 0 0 0 0 0 > >>>>>> #4 0 1 0 0 0 0 0 0 > >>>>>> #5 0 1 0 0 0 0 0 0 > >>>>>> #6 1 0 0 0 0 0 0 0 #7 > >>>>>> > >>> 1 0 > >>> > >>>>>> 0 0 0 0 0 0 #8 1 0 0 0 0 0 0 0 > >>>>>> > >>>>>> Where egress ports 3-5 are drop ports from Ingress 2 > and egress > >>>>>> ports 6-8 are drop ports from Ingress 1 and ingress > ports 3-5 are > >>>>>> add ports to Egress 2, ingress ports 6-8 are add ports to > >>>>>> > >>> Egress 1. > >>> > >>>>>> -----Original Message----- > >>>>>> From: ccamp-bounces@ietf.org > [mailto:ccamp-bounces@ietf.org] On > >>>>>> Behalf Of Giovanni Martinelli > >>>>>> Sent: Thursday, September 17, 2009 2:59 AM > >>>>>> To: Greg Bernstein > >>>>>> Cc: ccamp@ietf.org > >>>>>> Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM > >>>>>> > >>>>>> Hi Greg, > >>>>>> > >>>>>> Greg Bernstein wrote: > >>>>>> > >>>>>> > >>>>>>> Hi Giovanni, in the example given in section 5 (thanks > >>>>>>> > >>> to Dirk) we > >>> > >>>>>>> have multi-degree ROADMs. In section 3.3.1 we do > mention > >>>>>>> > >>>>>> higher degree > >>>>>> > >>>>>>> ROADMs but refer readers to another draft. Hmm, maybe > we > >>>>>>> > >>>>>> should also > >>>>>> > >>>>>>> point them to section 5. > >>>>>>> > >>>>>>> > >>>>>> um well Section 5 provide more a high level overview and > >>>>>> > >>> the scope > >>> > >>>>>> is a bit different while the other reference at the end still > >>>>>> contain 2 degree roadm (unless I'm missing something) > >>>>>> > >>>>>> This section was providing details about how a roadm > is presented > >>>>>> and the respective connectivity matrix (while in other > >>>>>> > >>> examples the > >>> > >>>>>> connectivity matrix only shows what is important for > the example > >>>>>> itself). > >>>>>> > >>>>>> To me this is important to show how exactly every roadm can be > >>>>>> represented (and I guess generalizing from 4 to n will > be clearer > >>>>>> than doing from 2 to n degree) and the size of the > >>>>>> > >>> matrix (then how > >>> > >>>>>> is sparse is another topic). > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> While I don't mind adding another picture, I think the > >>>>>>> > >>>>>> chairs will be > >>>>>> > >>>>>>> more interested in us reducing the length of the > document than > >>>>>>> expanding it ;-) . > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> well hope it's not the main criteria (we can always > shot for the > >>>>>> longest > >>>>>> RFC) ;-) > >>>>>> > >>>>>> Cheers > >>>>>> G > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Cheers > >>>>>>> > >>>>>>> Greg > >>>>>>> > >>>>>>> Giovanni Martinelli wrote: > >>>>>>> > >>>>>>> > >>>>>>>> Hi Greg & WSONers, > >>>>>>>> > >>>>>>>> well, I saw you just suggest a last call request but I > >>>>>>>> > >>> was > >>> > >>>>>> wondering > >>>>>> > >>>>>>>> about representing a more general case of ROAM in > section 3.3.1 > >>>>>>>> > >>>>>>>> The ID currently represent a 2 degree ROADM but looks > >>>>>>>> > >>> to me a very > >>> > >>>>>>>> specific case so I'm asking if it's ok adding a 4 > >>>>>>>> > >>> degree > >>> > >>>>>> ROADM as well. > >>>>>> > >>>>>> > >>>>>>>> Here just a rough idea starting from your current picture > >>>>>>>> > >>>>>>>> +---------------------+ > Line > >>>>>>>> > >>>>>> side-1 ingress > >>>>>> > >>>>>> > >>>>>>>> --->| |---> Line side-2 egress > >>>>>>>> Line side-1 egress <---| |<--- > >>>>>>>> > >>> Line side-2 > >>> > >>>>>>>> ingress > >>>>>>>> | ROADM | > >>>>>>>> Line side-3 ingress --->| |---> > >>>>>>>> > >>> Line > >>> > >>>>>> side-4 egress > >>>>>> > >>>>>> > >>>>>>>> Line side-3 egress <---| |<--- > >>>>>>>> > >>> Line side-4 > >>> > >>>>>>>> ingress > >>>>>>>> | | > >>>>>>>> +---------------------+ > >>>>>>>> | | | | o o o o > >>>>>>>> | | | | | | | | > >>>>>>>> O O O O | | | | > >>>>>>>> Tributary Side: Drop (egress) Add (ingress) > >>>>>>>> > >>>>>>>> > >>>>>>>> 1/ line sides likely have ingress and egress. > >>>>>>>> > >>>>>>>> > >>>>>>>> 2/ Tributaries might be associated to sides but I > would > >>>>>>>> > >>>>>> consider that > >>>>>> > >>>>>>>> as switching constrain. > >>>>>>>> > >>>>>>>> Does the switching matrix will apply in the same > way, > >>>>>>>> > >>>>>> become an 8x8 > >>>>>> > >>>>>>>> right?. > >>>>>>>> > >>>>>>>> Any thoughts about? > >>>>>>>> > >>>>>>>> > >>>>>>>> Cheers > >>>>>>>> G > >>>>>>>> _______________________________________________ > >>>>>>>> CCAMP mailing list > >>>>>>>> CCAMP@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> _______________________________________________ > >>>>>> CCAMP mailing list > >>>>>> CCAMP@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> CCAMP mailing list > >>>>>> CCAMP@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> CCAMP mailing list > >>>> CCAMP@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ccamp > >>>> > >>>> > >>> -- > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >>> Dr Greg Bernstein, Grotto Networking (510) 573-2237 > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > > > > -- > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > > > > > > From ylee@huawei.com Tue Sep 22 11:27:25 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE06C3A6AB6 for ; Tue, 22 Sep 2009 11:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 yEdY+XcnNBJX for ; Tue, 22 Sep 2009 11:27:22 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id F2CE23A68EF for ; Tue, 22 Sep 2009 11:27:21 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQD00JCEXZAKX@usaga04-in.huawei.com> for ccamp@ietf.org; Tue, 22 Sep 2009 13:28:23 -0500 (CDT) Received: from L73682 ([10.124.12.76]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KQD00BZIXZ3AN@usaga04-in.huawei.com> for ccamp@ietf.org; Tue, 22 Sep 2009 13:28:22 -0500 (CDT) Date: Tue, 22 Sep 2009 13:28:15 -0500 From: Young Lee In-reply-to: <4AB8E466.3020509@grotto-networking.com> To: 'Greg Bernstein' , =?iso-8859-1?Q?'Jonas_M=E5rtensson'?= Message-id: <002c01ca3bb2$74dd7b50$d626fea9@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_jlQZNg2FywGrLxdn4p/EBg)" Thread-index: Aco7lE7+ix53+cEWRaSzne+chFpIiAAHhlag References: <4AAFB210.8000802@cisco.com> <4AAFB6FF.2060301@grotto-networking.com> <4AB1EC48.2050407@cisco.com> <002001ca389a$1e7eb5a0$4c0c7c0a@china.huawei.com> <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BA4@acreoexc01.ad.acreo.se> <001d01ca3ad4$2c1127c0$4c0c7c0a@china.huawei.com> <4AB7A915.9000903@cisco.com> <4AB7C1F7.9040204@grotto-networking.com> <1EC35EEAF3A9FA439C7D6AE45BF43787016B55B27BBB@acreoexc01.ad.acreo.se> <4AB8E466.3020509@grotto-networking.com> Cc: ccamp@ietf.org Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM 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, 22 Sep 2009 18:27:25 -0000 This is a multi-part message in MIME format. --Boundary_(ID_jlQZNg2FywGrLxdn4p/EBg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Yes, the suggestion sounds good to me. Thanks. =20 Young =20 _____ =20 From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: Tuesday, September 22, 2009 9:51 AM To: Jonas M=E5rtensson Cc: Giovanni Martinelli; Young Lee; ccamp@ietf.org Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM =20 Thanks Jonas, this example seems good in that it illustrates: (a) Bi-directional ROADM (b) Higher degree ROADM (c) A more complicated connectivity matrix due to the per port type of add/drop connectivity. Although the number of add/drop ports is low we could comment in the = text that this is for simplicity in drawing the figure. I was thinking of then adding this example to section 3.3.1 after the = simple example of the unidirectional 2-degree ROADM.=20 How does that sound to you? Giovanni, Young, and others, does that = sound good to you? Best Regards Greg Jonas M=E5rtensson wrote:=20 Hi, =20 Greg, as you say, the encoding draft specifies an efficient way to = represent the connectivity of a switching node. However, the current = (uni-directional) examples in section 3.1.1 of the framework draft do not illustrate one reason why the encoding draft representation is efficient, which is that = the connectivity constraints for typical ROADM designs are "bi-directional", i.e. if ingress port X can (or can't) be connected to egress port Y, typically ingress port Y can (or can't) be connected to egress port X, assuming the numbering is done in such a way that ingress X and egress X correspond to the same line side direction or the same add/drop port. = This makes the connectivity matrix symmetrical (which can be taken advantage = of by setting the directionality bits of the link sets in the encoding = draft representation to bidirectional). Borrowing Giovanni's (slightly = modified) proposed 4-degree example with one (potentially multi-channel) add/drop = per line side port to illustra te :=20 =20 =20 +------------------------+ =20 Line side-1 ingress (I1) --->| |---> Line side-2 egress (E2) Line side-1 egress (E1) <---| |<--- Line side-2 ingress (I2) | ROADM | Line side-3 ingress (I3) --->| |---> Line side-4 egress (E4) Line side-3 egress (E3) <---| |<--- Line side-4 ingress (I4) | | +------------------------+ | O | O | O | O | | | | | | | | O | O | O | O | Tributary Side: E5 I5 E6 I6 E7 I7 E8 I8 =20 =20 Corresponding 8x8 sparse and symmetrical connectivity matrix: =20 Ingress Egress Port Port E1 E2 E3 E4 E5 E6 E7 E8 -------------- I1 0 1 1 1 0 1 0 0 I2 1 0 1 1 0 0 1 0 A =3D I3 1 1 0 1 1 0 0 0 I4 1 1 1 0 0 0 0 1 I5 0 0 1 0 0 0 0 0 I6 1 0 0 0 0 0 0 0=20 I7 0 1 0 0 0 0 0 0=20 I8 0 0 0 1 0 0 0 0 =20 where I5/E5 are add/drop ports to/from line side-3, I6/E6 are add/drop = ports to/from line side-1, I7/E7 are add/drop ports to/from line side-2 and = I8/E8 are add/drop ports to/from line side-4. Note that diagonal elements are = zero since I assume that loopback is not supported. If ports support = loopback, diagonal elements would be one. =20 Do you think such an example would be useful? =20 Regards, Jonas =20 =20 =20 -----Original Message----- From: Greg Bernstein [mailto:gregb@grotto-networking.com]=20 Sent: den 21 september 2009 20:12 To: Giovanni Martinelli Cc: Young Lee; ccamp@ietf.org; Jonas M=E5rtensson Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM =20 Hi folks, for the framework document we currently have an=20 example of a 2-Degree unidirectional ROADM. Which represents=20 about the simplest asymmetric switching system we can show. =20 The general connectivity matrix formulation is at its core=20 is unidirectional, i.e., deals with the potential=20 connectivity of each ingress and egress pair separately to be=20 generally applicable. Note that the encoding draft hits the=20 issue of how to represent this stuff compactly on the wire. =20 Note the size of the matrix is in terms of (# of ingress=20 ports) X (# of egress ports) and don't forget to include add=20 and drop ports. The interesting feature of higher degree=20 ROADMs is that two ROADMs of the same "degree" may have very=20 different connectivity properties. For example in=20 architectures based on add/drop per node versus add/drop per=20 fiber. In your 4-degree example Giovanni the number of add=20 and drop ports seemed rather small and seems to make it hard=20 to illustrate the difference between a "drop per node" and a=20 "drop per fiber" style architecture. =20 What aspects do you want to see illustrated most in this=20 section of the draft? I'm thinking of adding some text to=20 address the general case a bit more since the draft can refer=20 to a published paper (in JOCN) that furnishes a significant=20 number of examples of higher order and bidirectional ROADMs. =20 Cheers =20 Greg =20 Giovanni Martinelli wrote: =20 Hi, =20 Young Lee wrote: =20 Hi Jonas, =20 Yes you are right. Due to the ASCII limitation, the=20 =20 figures for both=20 =20 2-degree and 4-degree ROADM are shown only for one direction. =20 although ascii art difficult, I got the issue in=20 =20 understanding where=20 =20 bi-directionality apply as well. That's why I was trying to get all=20 directions in one picture (but not sure the result was ok). =20 =20 For your question (2), we have added a note that this ROADM is based on per=20 port add/drop (which is hard to show with ASCII) which=20 =20 means Ingress=20 =20 1(2) and Egress 1(2) are associated to the different directions. =20 =20 One more clarification on the topic: the fact that we represent=20 connectivity matrix done by (ingress x egress) it means we have a=20 matrix for each directions? =20 thx G =20 =20 Hope this clarifies your question... Thanks. Regards, Young =20 -----Original Message----- From: Jonas M=E5rtensson [mailto:Jonas.Martensson@acreo.se] Sent:=20 Monday, September 21, 2009 10:21 AM To: Young Lee; 'Giovanni Martinelli' Cc: ccamp@ietf.org Subject: RE: [CCAMP] rwa wson framework: multi-degree ROADM =20 Hi Young, =20 Actually, I think the figure you propose is a bit confusing for a=20 couple of reasons: =20 1) It only depicts either ingress or egress for the four=20 =20 directions=20 =20 while in practice links are typically bidirectional. (The same is=20 true for the degree-2 ROADM example in the draft but there it is less=20 =20 confusing.) =20 2) The way the ports are numbered, to me it looks like=20 =20 Ingress 1(2)=20 =20 and Egress 1(2) are associated to the same direction which=20 =20 means that=20 =20 to me it looks more like a degree-2 ROADM. =20 I think it would be clearer if you made all ports in the figures=20 bidirectional. =20 Regards, Jonas =20 =20 =20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 Behalf Of Young Lee Sent: den 18 september 2009 21:57 To: 'Giovanni Martinelli' Cc: ccamp@ietf.org Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM =20 Hi Giovanni, We have added 4-degree ROADM figure and connectivity=20 =20 matrix per your=20 =20 suggestion in the draft. Below is tentative text we have added in=20 Section 3.3.1. I hope this would satisfy your request. Thanks. Young ---------------------------------------------------------------- =20 Ingress 1 +---------------+ +---------------+ Egress 1=20 ----> | | -->| |---->=20 Ingress 2 | | | | Egress 2 ----> | | -->| |----> =20 +---------------+ +---------------+ | | | | | | O O O O O O | | | | | | | | | | | | O O O O O O | | | | | | E3 E4 E5 E6 E7 E8 I3 I4 I5 I6 I7 I8 Triburary Side Drop Add Figure 2 Degree-4 ROADM =20 For the ROADM of Figure 2 the switched connectivity matrix can be=20 expressed as follows. Note that this ROADM is based on per port=20 add/drop. Ingress Egress Port Port #1 #2 #3 #4 #5 #6 #7 #8 -------------- #1: 1 1 0 0 0 1 1 1 #2 1 1 1 1 1 0 0 0 A =3D #3 0 1 0 0 0 0 0 0 #4 0 1 0 0 0 0 0 0 #5 0 1 0 0 0 0 0 0 #6 1 0 0 0 0 0 0 0 #7 =20 =20 1 0 =20 =20 0 0 0 0 0 0 #8 1 0 0 0 0 0 0 0 =20 Where egress ports 3-5 are drop ports from Ingress 2 and egress=20 ports 6-8 are drop ports from Ingress 1 and ingress ports 3-5 are=20 add ports to Egress 2, ingress ports 6-8 are add ports to=20 =20 Egress 1. =20 -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On=20 Behalf Of Giovanni Martinelli Sent: Thursday, September 17, 2009 2:59 AM To: Greg Bernstein Cc: ccamp@ietf.org Subject: Re: [CCAMP] rwa wson framework: multi-degree ROADM =20 Hi Greg, =20 Greg Bernstein wrote: =20 =20 Hi Giovanni, in the example given in section 5 (thanks=20 =20 to Dirk) we=20 =20 have multi-degree ROADMs. In section 3.3.1 we do mention =20 =20 higher degree =20 =20 ROADMs but refer readers to another draft. Hmm, maybe we =20 =20 should also =20 =20 point them to section 5. =20 =20 um well Section 5 provide more a high level overview and=20 =20 the scope=20 =20 is a bit different while the other reference at the end still=20 contain 2 degree roadm (unless I'm missing something) =20 This section was providing details about how a roadm is presented=20 and the respective connectivity matrix (while in other=20 =20 examples the=20 =20 connectivity matrix only shows what is important for the example=20 itself). =20 To me this is important to show how exactly every roadm can be=20 represented (and I guess generalizing from 4 to n will be clearer=20 than doing from 2 to n degree) and the size of the=20 =20 matrix (then how=20 =20 is sparse is another topic). =20 =20 =20 =20 While I don't mind adding another picture, I think the =20 =20 chairs will be =20 =20 more interested in us reducing the length of the document than=20 expanding it ;-) . =20 =20 =20 well hope it's not the main criteria (we can always shot for the=20 longest RFC) ;-) =20 Cheers G =20 =20 =20 Cheers =20 Greg =20 Giovanni Martinelli wrote: =20 =20 Hi Greg & WSONers, =20 well, I saw you just suggest a last call request but I=20 =20 was =20 =20 wondering =20 =20 about representing a more general case of ROAM in section 3.3.1 =20 The ID currently represent a 2 degree ROADM but looks=20 =20 to me a very=20 =20 specific case so I'm asking if it's ok adding a 4=20 =20 degree =20 =20 ROADM as well. =20 =20 Here just a rough idea starting from your current picture =20 +---------------------+ Line =20 =20 side-1 ingress =20 =20 --->| |---> Line side-2 egress Line side-1 egress <---| |<--- =20 =20 Line side-2=20 =20 ingress | ROADM | Line side-3 ingress --->| |---> =20 =20 Line =20 =20 side-4 egress =20 =20 Line side-3 egress <---| |<--- =20 =20 Line side-4=20 =20 ingress | | +---------------------+ | | | | o o o o | | | | | | | | O O O O | | | | Tributary Side: Drop (egress) Add (ingress) =20 =20 1/ line sides likely have ingress and egress. =20 =20 2/ Tributaries might be associated to sides but I would =20 =20 consider that =20 =20 as switching constrain. =20 Does the switching matrix will apply in the same way, =20 =20 become an 8x8 =20 =20 right?. =20 Any thoughts about? =20 =20 Cheers G _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp =20 =20 =20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp =20 =20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp =20 =20 =20 =20 =20 =20 =20 =20 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp =20 =20 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =20 =20 =20 =20 =20 =20 =20 =20 --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Dr Greg Bernstein, Grotto Networking (510) 573-2237 =20 --Boundary_(ID_jlQZNg2FywGrLxdn4p/EBg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable

Yes, the suggestion sounds good to = me. Thanks.

 

Young

 

From: Greg Bernstein [mailto:gregb@grotto-networking.com] =
Sent: Tuesday, September = 22, 2009 9:51 AM
To: Jonas = M=E5rtensson
Cc: Giovanni Martinelli; = Young Lee; ccamp@ietf.org
Subject: Re: [CCAMP] rwa = wson framework: multi-degree ROADM

 

Thanks Jonas, this example seems good in = that it illustrates:
(a) Bi-directional ROADM
(b) Higher degree ROADM
(c) A more complicated connectivity matrix due to the per port type of = add/drop connectivity.

Although the number of add/drop ports is low we could comment in the = text that this is for simplicity in drawing the figure.
I was thinking of then adding this example to section 3.3.1 after the = simple example of the unidirectional 2-degree ROADM.
How does that sound to you?  Giovanni, Young, and others, does that = sound good to you?

Best Regards

Greg

Jonas M=E5rtensson wrote: 

Hi,
 
Greg, as you say, the encoding draft =
specifies an efficient way to represent the connectivity of a switching =
node. However, the current (uni-directional) examples in section 3.1.1 =
of the framework draft do not illustrate one reason why the encoding =
draft representation is efficient, which is that the connectivity =
constraints for typical ROADM designs are "bi-directional", =
i.e. if ingress port X can (or can't) be connected to egress port Y, =
typically ingress port Y can (or can't) be connected to egress port X, =
assuming the numbering is done in such a way that ingress X and egress X =
correspond to the same line side direction or the same add/drop port. =
This makes the connectivity matrix symmetrical (which can be taken =
advantage of by setting the directionality bits of the link sets in the =
encoding draft representation to bidirectional). Borrowing Giovanni's =
(slightly modified) proposed 4-degree example with one (potentially =
multi-channel) add/drop per line side port to =
illustra
te : =

 
 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +------------------------+=A0 =

Line side-1 ingress (I1) =
--->|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 |--->=A0 Line side-2 egress =
(E2)
Line side-1 egress (E1)=A0 =
<---|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 |<---=A0 Line side-2 ingress =
(I2)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 =
ROADM=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|
Line side-3 ingress (I3) =
--->|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 |--->=A0 Line side-4 egress =
(E4)
Line side-3 egress (E3)=A0 =
<---|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 |<---=A0 Line side-4 ingress =
(I4)
=A0=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
+------------------------+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | O=A0=A0=A0 | O=A0=A0=A0 | =
O=A0=A0=A0 | O
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | |=A0=A0=A0 | |=A0=A0=A0 | =
|=A0=A0=A0 | |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 O |=A0=A0=A0 O |=A0=A0=A0 O =
|=A0=A0=A0 O |
=A0=A0=A0=A0=A0=A0=A0=A0 Tributary =
Side:=A0=A0=A0=A0 E5 I5=A0 E6 I6=A0 E7 I7=A0 E8 =
I8
 
 
Corresponding 8x8 sparse and symmetrical =
connectivity matrix:
 
=A0=A0=A0=A0=A0=A0=A0 Ingress Egress =
Port
=A0=A0=A0=A0=A0=A0=A0 =
Port=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 E1 E2=A0=A0 E3 E4=A0=A0 E5 E6 E7 =
E8
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 =
--------------
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
I1=A0=A0=A0=A0=A0 0=A0 1 =A0=A0 1=A0 1=A0 0=A0 1 =A0=A0=A0 0=A0 =
0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
I2=A0=A0=A0=A0=A0 1=A0 0=A0 1=A0 1=A0 0=A0 0 =A0=A0=A0=A0=A0 1=A0 =
0
=A0=A0 =A0=A0=A0=A0 A =3D=A0=A0=A0=A0 =
I3=A0=A0=A0=A0=A0 1=A0 1 =A0=A0 0=A0 1 =A0=A0 1=A0 0=A0 0=A0 =
0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
I4=A0=A0=A0=A0=A0 1=A0 1 =A0=A0 1=A0 0 =A0=A0 0=A0 0=A0=A0=A0 0=A0 =
1
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
I5=A0=A0=A0=A0=A0 0=A0 0 =A0=A0 1=A0 0 =A0=A0 0=A0 0=A0 0=A0 =
0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I6=A0=A0=A0 =
1=A0 0=A0 0=A0 0=A0 0=A0 0=A0 0=A0 0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0I7=A0=A0 =
=A0=A0=A0=A0=A0 0=A0 1=A0 0=A0 0=A0 0=A0 0=A0 0=A0 0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0I8=A0=A0=A0=
 0=A0 0=A0 0=A0 1=A0 0=A0 0=A0 0=A0 =
0
 
where I5/E5 are add/drop ports to/from line =
side-3, I6/E6 are add/drop ports to/from line side-1, I7/E7 are add/drop =
ports to/from line side-2 and I8/E8 are add/drop ports to/from line =
side-4. Note that diagonal elements are zero since I assume that =
loopback is not supported. If ports support loopback, diagonal elements =
would be one.
 
Do you think such an example would be =
useful?
 
Regards,
Jonas
 
 
=A0 



-----Original =
Message-----
From: Greg Bernstein [mailto:gregb@grotto-networkin=
g.com] 
Sent: den 21 september 2009 =
20:12
To: Giovanni =
Martinelli
Cc: Young Lee; ccamp@ietf.org; Jonas =
M=E5rtensson
Subject: Re: [CCAMP] rwa wson framework: =
multi-degree ROADM
 
Hi folks, for the framework document we =
currently have an 
example of a 2-Degree unidirectional ROADM. =
Which represents 
about the simplest asymmetric switching=A0 =
system we can show.=A0 
The=A0 general connectivity matrix=A0 =
formulation is at its core 
is unidirectional, i.e.,=A0 deals with the =
potential 
connectivity of each ingress and egress pair =
separately to be 
generally applicable. Note that the encoding =
draft hits the 
issue of how to represent this stuff =
compactly on the wire.
 
Note the size of the=A0 matrix is in terms of =
(# of ingress 
ports) X=A0 (# of egress ports) and don't =
forget to include add 
and drop ports. The interesting feature of =
higher degree 
ROADMs is that two ROADMs of the same =
"degree"=A0 may have very =

different connectivity properties. For =
example in 
architectures based on add/drop per node =
versus add/drop per 
fiber. In your 4-degree example Giovanni the =
number of add 
and drop ports seemed rather small and seems =
to make it hard 
to illustrate the difference between a =
"drop per node" and a =

"drop per fiber" style =
architecture.
 
What aspects do you want to see illustrated =
most in this 
section of the draft? I'm thinking of adding =
some=A0 text to 
address the general case a bit more since the =
draft can refer 
to a published paper (in JOCN) that furnishes =
a significant 
number of examples of higher order and =
bidirectional ROADMs.
 
Cheers
 
Greg
 
Giovanni Martinelli =
wrote:
=A0=A0=A0 



Hi,
 
Young Lee =
wrote:
=A0=A0=A0=A0=A0 =




Hi =
Jonas,
 
Yes you are right. Due to the ASCII =
limitation, the 
=A0=A0=A0=A0=A0=A0=A0=A0






figures for both =

=A0=A0=A0=A0






2-degree and 4-degree ROADM are shown only =
for one direction.
=A0=A0=A0=A0=A0=A0=A0 =




although ascii art difficult, I got the issue =
in 
=A0=A0=A0=A0=A0=A0



understanding where =

=A0=A0=A0=A0



bi-directionality apply as well. That's why I =
was trying to get all 
directions in one picture (but not sure the =
result was ok).
 
=A0=A0=A0=A0=A0 =




For =
your
question (2), we have added a note that this =
ROADM is based on per 
port add/drop (which is hard to show with =
ASCII) which 
=A0=A0=A0=A0=A0=A0=A0=A0






means Ingress =

=A0=A0=A0=A0






1(2) and Egress 1(2) are associated to the =
different directions.
=A0 
=A0=A0=A0=A0=A0=A0=A0=A0



One more clarification on the topic: the fact =
that we represent 
connectivity matrix done by (ingress x =
egress) it means we have a 
matrix for each =
directions?
 
thx
G
 
=A0=A0=A0=A0=A0 =




Hope this clarifies your question... =
Thanks.
Regards,
Young
 
-----Original =
Message-----
From: Jonas M=E5rtensson [mailto:Jonas.Martensson@acreo.s=
e] Sent: 
Monday, September 21, 2009 10:21 =
AM
To: Young Lee; 'Giovanni =
Martinelli'
Cc: ccamp@ietf.org
Subject: RE: [CCAMP] rwa wson framework: =
multi-degree ROADM
 
Hi =
Young,
 
Actually, I think the figure you propose is a =
bit confusing for a 
couple =
of
reasons:
 
1) It only depicts either ingress or egress =
for the four 
=A0=A0=A0=A0=A0=A0=A0=A0






directions =

=A0=A0=A0=A0






while in practice links are typically =
bidirectional. (The same is 
true for =
the
degree-2 ROADM example in the draft but there =
it is less 
=A0=A0=A0=A0=A0=A0=A0=A0






confusing.)
=A0=A0=A0 
2) The way the ports are numbered, to me it =
looks like 
=A0=A0=A0=A0=A0=A0=A0=A0
Ingress 1(2) =

=A0=A0=A0=A0
and Egress 1(2) are associated to the same =
direction which 
=A0=A0=A0=A0=A0=A0=A0=A0
means that =

=A0=A0=A0=A0
to me it looks more like a degree-2 =
ROADM.
 
I think it would be clearer if you made all =
ports in the figures 
bidirectional.
<= pre> 
Regards,
Jonas
 
 
=A0=A0=A0=A0=A0=A0=A0=A0
-----Original =
Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=
 On 
Behalf Of Young =
Lee
Sent: den 18 september 2009 =
21:57
To: 'Giovanni =
Martinelli'
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] rwa wson framework: =
multi-degree ROADM
 
Hi =
Giovanni,
We have added 4-degree ROADM figure and =
connectivity 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
matrix per your =

=A0=A0=A0=A0
suggestion in the draft. Below is tentative =
text we have added in 
Section 3.3.1. I hope this would satisfy your =
request.
Thanks.
Young
----------------------------------------------=
------------------
 
Ingress 1=A0 +---------------+=A0=A0=A0 =
+---------------+=A0=A0=A0 Egress 1 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0-=
---> |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =
-->|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |----> =

Ingress 2=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 Egress =
2
=A0=A0=A0=A0 ----> =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =
-->|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|---->=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

+---------------+=A0=A0=A0 =
+---------------+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | | =
|=A0=A0=A0 | | |=A0=A0=A0=A0=A0 O O O=A0=A0=A0=A0 O O =
O
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | | =
|=A0=A0=A0 | | |=A0=A0=A0=A0=A0 | | |=A0=A0=A0=A0 | | =
|
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 O O =
O=A0=A0=A0 O O O=A0=A0=A0=A0=A0 | | |=A0=A0=A0=A0 | | =
|
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 E3 E4 =
E5=A0 E6 E7 E8=A0=A0 I3 I4 I5=A0 I6 I7 =
I8
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Triburary Side=A0=A0=A0=A0 =
Drop=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Add
Figure 2 =A0=A0=A0Degree-4 =
ROADM
 
For the ROADM of Figure 2 the switched =
connectivity matrix can be 
expressed as follows. Note that this ROADM is =
based on per port 
add/drop.
<=
font
size=3D2 color=3Dblack face=3D"Courier New">=A0=A0=A0 Ingress=A0=A0=A0 Egress =
Port
=A0=A0=A0 Port=A0=A0=A0=A0=A0=A0=A0 #1 =
#2=A0=A0=A0 #3 #4=A0=A0=A0 #5 #6 #7 =
#8
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
--------------
=A0=A0=A0=A0=A0=A0=A0 #1:=A0=A0=A0 1=A0 =
1=A0=A0=A0=A0 0=A0 0=A0 0=A0 1=A0=A0=A0=A0 1=A0 =
1
=A0=A0=A0=A0=A0=A0=A0 #2=A0=A0=A0 1=A0 1=A0 =
1=A0 1=A0 1=A0 0=A0=A0=A0=A0 0=A0 =
0
=A0=A0=A0=A0=A0=A0 A =3D=A0=A0=A0 #3=A0=A0=A0 =
0=A0 1=A0=A0=A0=A0 0=A0 0=A0=A0=A0=A0 0=A0 0=A0 0=A0 =
0
=A0=A0=A0=A0=A0=A0=A0 #4=A0=A0=A0 0=A0 =
1=A0=A0=A0=A0 0=A0 0=A0=A0=A0=A0 0=A0 0=A0=A0=A0 0=A0 =
0
=A0=A0=A0=A0=A0=A0=A0 #5=A0=A0=A0 0=A0 =
1=A0=A0=A0=A0 0=A0 0=A0=A0=A0=A0 0=A0 0=A0 0=A0 =
0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 #6=A0=A0=A0 =
1=A0 0=A0 0=A0 0=A0 0=A0 0=A0 0=A0 0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
#7=A0=A0 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
=A0=A0=A0 1=A0 0=A0 =

=A0=A0=A0=A0
0=A0 0=A0 0=A0 0=A0 0=A0 =
0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 #8=A0=A0=A0 1=A0 0=A0 0=A0 0=A0 =
0=A0 0=A0 0=A0 0
=A0 
Where egress ports 3-5 are drop ports from =
Ingress 2 and egress 
ports 6-8 are drop ports from Ingress 1 and =
ingress ports 3-5 are 
add ports to Egress 2, ingress ports 6-8 are =
add ports to 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
Egress =
1.
=A0=A0=A0 
-----Original =
Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=
 On 
Behalf Of Giovanni =
Martinelli
Sent: Thursday, September 17, 2009 2:59 =
AM
To: Greg =
Bernstein
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] rwa wson framework: =
multi-degree ROADM
 
Hi =
Greg,
 
Greg Bernstein =
wrote:
 =
=A0=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
Hi Giovanni, in the example given in section =
5 (thanks 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
to Dirk) we =

=A0=A0=A0=A0
have multi-degree ROADMs. In section 3.3.1 we =
do mention=A0=A0=A0=A0=A0=A0 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
higher degree=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
ROADMs but refer readers to another draft. =
Hmm, maybe we=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
should also=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
point them to section =
5.
=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
um well Section 5 provide more a high level =
overview and 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
the scope =

=A0=A0=A0=A0
is a bit different while the other reference =
at the end still 
contain 2 degree roadm (unless I'm missing =
something)
 
This section was providing details about how =
a roadm is presented 
and the respective connectivity matrix (while =
in other 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
examples the =

=A0=A0=A0=A0
connectivity matrix only shows what is =
important for the example 
itself).
 
To me this is important to show how exactly =
every roadm can be 
represented (and I guess generalizing from 4 =
to n will be clearer 
than doing from 2 to n degree) and the size =
of=A0 the 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
matrix (then how =

=A0=A0=A0=A0
is sparse is another =
topic).
 
 
=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
While I don't mind adding another picture, I =
think the=A0=A0=A0=A0=A0=A0 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
chairs will be=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
more interested in us reducing the length of =
the document than 
expanding it ;-) =
.
 
=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
well hope it's not the main criteria (we can =
always shot for the 
longest
RFC) =
;-)
 
Cheers
G
 
=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
Cheers
 
Greg
 
Giovanni Martinelli =
wrote:
=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
Hi Greg & =
WSONers,
 
well, I saw you just suggest a last call =
request but I 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
was=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0
wondering=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
about representing a more general case of =
ROAM in section 3.3.1
 
The ID currently represent a 2 degree ROADM =
but looks 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
to me a very =

=A0=A0=A0=A0
specific case so I'm asking if it's ok adding =
a 4 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
degree=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0
ROADM as =
well.
=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
Here just a rough idea starting from your =
current picture
 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 +---------------------+=A0 =
Line=A0=A0=A0=A0=A0=A0=A0=A0 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
side-1 =
ingress
=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
--->|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 |--->=A0 Line side-2 =
egress
Line side-1 egress=A0=A0 =
<---|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|<---=A0 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
Line side-2 =

=A0=A0=A0=A0
ingress
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 ROADM=A0=A0=A0=A0=A0=A0=A0 =
|
Line side-3 ingress=A0 =
--->|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|--->=A0 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
Line=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0
side-4 =
egress
=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
Line side-3 egress=A0=A0 =
<---|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|<---=A0 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
Line side-4 =

=A0=A0=A0=A0
ingress
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
|
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 =
+---------------------+
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | | | |=A0 o o o =
o
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | | | |=A0 | | | =
|
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 O O O O=A0 | | | =
|
=A0=A0=A0=A0 Tributary Side:=A0=A0 Drop =
(egress)=A0 Add (ingress)
 
 
1/ line sides likely have ingress and =
egress.
 
 
2/ Tributaries might be associated to sides =
but I would=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
consider that=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
as=A0 switching =
constrain.
 
Does the switching matrix will apply in the =
same way,=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
become an 8x8=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
right?.
 
Any thoughts =
about?
 
 
Cheers
G
______________________________________________=
_
CCAMP mailing =
list
CCAMP@ietf.org
https://www.ietf.org=
/mailman/listinfo/ccamp
 
=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
______________________________________________=
_
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
 
 
=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
 
 
=A0 
=A0=A0=A0=A0=A0=A0=A0=A0
______________________________________________=
_
CCAMP mailing =
list
CCAMP@ietf.org
https://www.ietf.org=
/mailman/listinfo/ccamp
 
=A0=A0=A0=A0=A0 =

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

 
 
=A0 



-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, Grotto Networking (510) =
573-2237
 
--Boundary_(ID_jlQZNg2FywGrLxdn4p/EBg)-- From lberger@labn.net Tue Sep 22 11:39:10 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0433A68F6 for ; Tue, 22 Sep 2009 11:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.217, 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 Jk-t3afiXFX2 for ; Tue, 22 Sep 2009 11:39:09 -0700 (PDT) Received: from outbound-mail-120.bluehost.com (outbound-mail-120.bluehost.com [69.89.18.6]) by core3.amsl.com (Postfix) with SMTP id 1B7E53A691D for ; Tue, 22 Sep 2009 11:39:09 -0700 (PDT) Received: (qmail 3575 invoked by uid 0); 22 Sep 2009 18:40:13 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy3.bluehost.com with SMTP; 22 Sep 2009 18:40:12 -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=Y3weESgKdkkscm8tbIgs/w9d1pH7u+TrQoI/5L2ixuC9geZEZXVPcdMPZfGrTthxgDcsDtuGbEqQIk6NxH6oLijhyAEFeIIe1XLIU8dQ/YSByugrfrN/dgZFjv7bg1fH; 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 1MqAHc-0007gd-OF; Tue, 22 Sep 2009 12:40:12 -0600 Message-ID: <4AB91A12.3010404@labn.net> Date: Tue, 22 Sep 2009 14:40:18 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Adrian Farrel X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org, iesg-secretary@ietf.org Subject: [CCAMP] Please publish: draft-ietf-ccamp-pc-spc-rsvpte-ext-04 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, 22 Sep 2009 18:39:10 -0000 Proto-write-up for: draft-ietf-ccamp-pc-spc-rsvpte-ext-04 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. > If such normative references exist, what is the > strategy for their completion? N/A. > Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. No downward references. > >(1.i) Has the Document Shepherd verified that the document's IANA > Considerations section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC2434]. If the > document describes an Expert Review process, has the Document > Shepherd conferred with the Responsible Area Director so that > the IESG can appoint the needed Expert during IESG Evaluation? The IANA section looks. >(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 memo describes an extension to Generalized Multi-Protocol Label Switching 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 rversion to original state. A basic premise of the extension is that the handover procedures must never impact an already established data plane. > Working Group Summary > Was there anything in the WG process that is worth noting? > For example, was there controversy about particular points > or were there decisions where the consensus was > particularly rough? This document received adequate attention and discussion 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 > Are there existing implementations of the protocol? Have a > significant number of vendors indicated their plan to > implement the specification? Are there any reviewers that > merit special mention as having done a thorough review, > e.g., one that resulted in important changes or a > conclusion that the document had no substantive issues? If > there was a MIB Doctor, Media Type, or other Expert Review, > what was its course (briefly)? In the case of a Media Type > Review, on what date was the request posted? > There have been no public statements related to intent to implement, but it is expected that some/all of the primary Authors plan to implement. > Personnel > Who is the Document Shepherd for this document? Lou Berger. > Who is the > Responsible Area Director? Adrian Farrel > If the document requires IANA > experts(s), insert 'The IANA Expert(s) for the registries > in this document are .' > From lberger@labn.net Wed Sep 23 08:59:34 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8EE3A6A4D for ; Wed, 23 Sep 2009 08:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.055 X-Spam-Level: X-Spam-Status: No, score=-2.055 tagged_above=-999 required=5 tests=[AWL=0.210, 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 D-JVgWdV9E7s for ; Wed, 23 Sep 2009 08:59:33 -0700 (PDT) Received: from outbound-mail-07.bluehost.com (outbound-mail-07.bluehost.com [69.89.17.207]) by core3.amsl.com (Postfix) with SMTP id 44BA23A69BA for ; Wed, 23 Sep 2009 08:59:33 -0700 (PDT) Received: (qmail 29335 invoked by uid 0); 23 Sep 2009 16:00:39 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy1.bluehost.com with SMTP; 23 Sep 2009 16:00:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=sjA5TgEPY6MESgQmtxNpIvo2LLcNfwFm7tuDHRwarkQCrvHe+jeeIXtVrfFOBHEquUeKGr/qKtqZvH6G76hzk7Gqlyyx05Jq9ETRd9rNLcJXAQ9daxvdnCwgK2bpE3I5; 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 1MqUGk-0006xB-1R for ccamp@ietf.org; Wed, 23 Sep 2009 10:00:39 -0600 Message-ID: <4ABA462B.9020105@labn.net> Date: Wed, 23 Sep 2009 12:00:43 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: ccamp@ietf.org References: <4AA6C495.4080306@labn.net> In-Reply-To: <4AA6C495.4080306@labn.net> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] 2nd Working group last call: draft-ietf-ccamp-lsp-dppm 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, 23 Sep 2009 15:59:34 -0000 This last call is complete. Authors please submit any revisions you may have, and summarize changes to the list. Lou On 9/8/2009 4:54 PM, Lou Berger wrote: > This email begins a two week working group last call on > draft-ietf-ccamp-lsp-dppm-08.txt > > http://tools.ietf.org/html/draft-ietf-ccamp-lsp-dppm-08 > > Please send your comments to the list or the authors before the last > call closes on September 22, 2009. > > As discussed on the list, we are holding an additional last call on > this draft due to the changes made as a result of the previous Last > Call. For convenience, here's the url to see the diff: > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-ietf-ccamp-lsp-dppm-05.txt&url2=draft-ietf-ccamp-lsp-dppm-08.txt > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > From wwwrun@core3.amsl.com Thu Sep 24 12:04:47 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 279BF3A6838; Thu, 24 Sep 2009 12:04:46 -0700 (PDT) From: Deborah Brungard(IETF CCAMP WG) To: George.Young@att.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090924190447.279BF3A6838@core3.amsl.com> Date: Thu, 24 Sep 2009 12:04:47 -0700 (PDT) Cc: ccamp@ietf.org, sjtrowbridge@alcatel-lucent.com, paf@cisco.com, Adrian.Farrel@huawei.com, rcallon@juniper.com Subject: [CCAMP] New Liaison Statement, "Response to your ITU-T SG15 OTNT Standardization Work Plan (December 2008)" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dbrungard@att.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 19:04:47 -0000 Title: Response to your ITU-T SG15 OTNT Standardization Work Plan (December 2008) Submission Date: 2009-09-24 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=586 From: Deborah Brungard(IETF CCAMP WG) To: ITU-T SG15 Question 3(George.Young@att.com) Cc: Greg.Jones@itu.int sjtrowbridge@alcatel-lucent.com paf@cisco.com Adrian.Farrel@huawei.com rcallon@juniper.com lberger@labn.net ccamp@ietf.org Reponse Contact: dbrungard@att.com Technical Contact: dbrungard@att.com Purpose: For information Body: The CCAMP Working Group of IETF thanks Question 3 for sharing their Work Plan in a liaison from the December 2008 meeting. We have updated Table 7-1-2 for the CCAMP related work. Best regards, Lou Berger and Deborah Brungard Co-Chairs of the CCAMP WG Attachment(s): SG15 OTNT Standardization Work Plan Table 7-1-2 Update (https://datatracker.ietf.org/documents/LIAISON/file702.pdf) From dbrungard@att.com Thu Sep 24 12:07:34 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468AB3A69B8 for ; Thu, 24 Sep 2009 12:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.715 X-Spam-Level: X-Spam-Status: No, score=-105.715 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799, 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 cn1WysA64kVq for ; Thu, 24 Sep 2009 12:07:33 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 4AACD3A6838 for ; Thu, 24 Sep 2009 12:07:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-3.tower-120.messagelabs.com!1253819319!39689400!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 21526 invoked from network); 24 Sep 2009 19:08:40 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Sep 2009 19:08:40 -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 n8OJ8a5e021372; Thu, 24 Sep 2009 15:08:37 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n8OJ8YXQ021342; Thu, 24 Sep 2009 15:08:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Thu, 24 Sep 2009 15:08:32 -0400 Message-ID: In-Reply-To: <20090924190447.279BF3A6838@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Liaison Statement, "Response to your ITU-T SG15 OTNT Standardization Work Plan (December 2008)" Thread-Index: Aco9ShI0fn8yRTLQTMCKE0Ot1KLeygAABAEQ References: <20090924190447.279BF3A6838@core3.amsl.com> From: "BRUNGARD, DEBORAH A, ATTLABS" To: Cc: ccamp@ietf.org, sjtrowbridge@alcatel-lucent.com, paf@cisco.com, Adrian.Farrel@huawei.com, rcallon@juniper.com Subject: Re: [CCAMP] New Liaison Statement, "Response to your ITU-T SG15 OTNT Standardization Work Plan (December 2008)" 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, 24 Sep 2009 19:07:34 -0000 UGxlYXNlIGlnbm9yZSAtIHRoZSBsaW5rIHdhcyBicm9rZW4gb24gdGhlIHByZXZpb3VzIHN1Ym1p c3Npb24gYW5kIHRoZSBsaWFpc29uIHRvb2wgcmVxdWlyZWQgYSBuZXcgdXBsb2FkIHRvIGNvcnJl Y3QuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCUlVOR0FSRCwgREVCT1JB SCBBLCBBVFRMQUJTIA0KU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyNCwgMjAwOSAzOjA1IFBN DQpUbzogR2VvcmdlLllvdW5nQGF0dC5jb20NCkNjOiBHcmVnLkpvbmVzQGl0dS5pbnQ7IHNqdHJv d2JyaWRnZUBhbGNhdGVsLWx1Y2VudC5jb207IHBhZkBjaXNjby5jb207IEFkcmlhbi5GYXJyZWxA aHVhd2VpLmNvbTsgcmNhbGxvbkBqdW5pcGVyLmNvbTsgbGJlcmdlckBsYWJuLm5ldDsgY2NhbXBA aWV0Zi5vcmc7IEJSVU5HQVJELCBERUJPUkFIIEEsIEFUVExBQlM7IEJSVU5HQVJELCBERUJPUkFI IEEsIEFUVExBQlMNClN1YmplY3Q6IE5ldyBMaWFpc29uIFN0YXRlbWVudCwgIlJlc3BvbnNlIHRv IHlvdXIgSVRVLVQgU0cxNSBPVE5UIFN0YW5kYXJkaXphdGlvbiBXb3JrIFBsYW4gKERlY2VtYmVy IDIwMDgpIiANCg0KDQpUaXRsZTogUmVzcG9uc2UgdG8geW91ciBJVFUtVCBTRzE1IE9UTlQgU3Rh bmRhcmRpemF0aW9uIFdvcmsgUGxhbiAoRGVjZW1iZXIgMjAwOCkNClN1Ym1pc3Npb24gRGF0ZTog MjAwOS0wOS0yNA0KVVJMIG9mIHRoZSBJRVRGIFdlYiBwYWdlOiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL3B1YmxpYy9saWFpc29uX2RldGFpbC5jZ2k/ZGV0YWlsX2lkPTU4NiANCg0KRnJv bTogRGVib3JhaCBCcnVuZ2FyZChJRVRGIENDQU1QIFdHKSA8ZGJydW5nYXJkQGF0dC5jb20+DQpU bzogSVRVLVQgU0cxNSBRdWVzdGlvbiAzKEdlb3JnZS5Zb3VuZ0BhdHQuY29tKQ0KQ2M6IEdyZWcu Sm9uZXNAaXR1LmludA0Kc2p0cm93YnJpZGdlQGFsY2F0ZWwtbHVjZW50LmNvbQ0KcGFmQGNpc2Nv LmNvbQ0KQWRyaWFuLkZhcnJlbEBodWF3ZWkuY29tDQpyY2FsbG9uQGp1bmlwZXIuY29tDQpsYmVy Z2VyQGxhYm4ubmV0DQpjY2FtcEBpZXRmLm9yZw0KUmVwb25zZSBDb250YWN0OiBkYnJ1bmdhcmRA YXR0LmNvbQ0KVGVjaG5pY2FsIENvbnRhY3Q6IGRicnVuZ2FyZEBhdHQuY29tDQpQdXJwb3NlOiBG b3IgaW5mb3JtYXRpb24gDQpCb2R5OiBUaGUgQ0NBTVAgV29ya2luZyBHcm91cCBvZiBJRVRGIHRo YW5rcyBRdWVzdGlvbiAzIGZvciBzaGFyaW5nIHRoZWlyIFdvcmsgUGxhbiBpbiBhIGxpYWlzb24g ZnJvbSB0aGUgRGVjZW1iZXIgMjAwOCBtZWV0aW5nLiBXZSBoYXZlIHVwZGF0ZWQgVGFibGUgNy0x LTIgZm9yIHRoZSBDQ0FNUCByZWxhdGVkIHdvcmsuDQoNCkJlc3QgcmVnYXJkcywNCkxvdSBCZXJn ZXIgYW5kIERlYm9yYWggQnJ1bmdhcmQNCkNvLUNoYWlycyBvZiB0aGUgQ0NBTVAgV0cNCkF0dGFj aG1lbnQocyk6DQogICAgIFNHMTUgT1ROVCBTdGFuZGFyZGl6YXRpb24gV29yayBQbGFuIFRhYmxl IDctMS0yIFVwZGF0ZSAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2N1bWVudHMvTElB SVNPTi9maWxlNzAyLnBkZikNCg0KDQoNCg== From loa@pi.nu Fri Sep 25 03:20:59 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04E063A691E; Fri, 25 Sep 2009 03:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 DjuljQ+MJ8FE; Fri, 25 Sep 2009 03:20:58 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 2F22B3A68A5; Fri, 25 Sep 2009 03:20:58 -0700 (PDT) Received: from [192.36.158.110] (wdhcp-158-110.verkstad.net [192.36.158.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 99DBCD4052; Fri, 25 Sep 2009 12:22:06 +0200 (CEST) Message-ID: <4ABC99CC.5080602@pi.nu> Date: Fri, 25 Sep 2009 12:22:04 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" , mpls@ietf.org, pwe3@ietf.org, ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] RFC5654 "MPLS-TP Requirements" has been published 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, 25 Sep 2009 10:20:59 -0000 All, RFC5654 "MPLS-TP Requirements" has now been published. Please join me in congratulating the authors and editor to a very good job. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From root@core3.amsl.com Sun Sep 27 05:00:02 2009 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 28EB33A689E; Sun, 27 Sep 2009 05:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090927120002.28EB33A689E@core3.amsl.com> Date: Sun, 27 Sep 2009 05:00:02 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-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: Sun, 27 Sep 2009 12: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 : Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks Author(s) : W. Sun, et al. Filename : draft-ietf-ccamp-lsp-dppm-09.txt Pages : 52 Date : 2009-09-27 Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. The dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic LSP provisioning performance in GMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can be used to characterize the features of GMPLS networks in LSP dynamic provisioning. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-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-lsp-dppm-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-27045853.I-D@ietf.org> --NextPart-- From sunwq@MIT.EDU Sun Sep 27 05:15:32 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B293E3A6984 for ; Sun, 27 Sep 2009 05:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVIUhMMc6F2z for ; Sun, 27 Sep 2009 05:15:31 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id A02FC3A6835 for ; Sun, 27 Sep 2009 05:15:31 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n8RCGhWM019929 for ; Sun, 27 Sep 2009 08:16:44 -0400 (EDT) Received: from APC (84.155.38.58.broad.xw.sh.dynamic.163data.com.cn [58.38.155.84] (may be forged)) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n8RCGdQ2024148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 27 Sep 2009 08:16:42 -0400 (EDT) Message-ID: From: "Weiqiang Sun" To: References: <20090927120002.28EB33A689E@core3.amsl.com> In-Reply-To: <20090927120002.28EB33A689E@core3.amsl.com> Date: Sun, 27 Sep 2009 20:16:32 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-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: Sun, 27 Sep 2009 12:15:32 -0000 Hi all, Based on the LC comments and a final review by the authors, we have revised the LSP DPPM draft and the changes are summarized below. 1. ``The Maximum of Metric" added as 14.3 The maximum of metric is the maximum of all the dT values in the sample. In computing this, undefined values MUST NOT be included. Note that this means that measurements that exceed the upper bound are not reported in this statistic. This is an important consideration when evaluating the maximum when the number of undefined measurements is non-zero. 2. A ``Metric Reporting" subsection is added to 4.8, 5.8, 6.8, 7.8, 8.8, 9.8, 10.8, 11.8, 12.8, 13.7. In 4.8 and 6.8, the text is: The metric result (either a real or an undefined value) MUST be reported together with the selected uppper bound. The route that the LSP tranverses MUST also be reported. In 5.8 and 7.8, the text is: The metric result (either a real or an undefined value) MUST be reported together with the selected uppper bound. The route that the LSPs tranverse MUST also be reported. In 8.8, the text is: The metric result (either a real or an undefined value) MUST be reported together with the selected uppper bound and the procedure used (eg. either from the ingress node to the egress node, or from the egress node to the ingress node. See Section 8.5 for more details). The route that the LSP tranverses MUST also be reported. In 9.8, 10.8, 11.8 and 12.8, the text is: The metric results including both real and undefined values MUST be reported together with the total number of values. The context under which the sample is obtained, including the selected parameters, the route traversed by the LSPs, and the testing case used MUST also be reported. In 13.7, the text is: The metric results including both real and undefined values MUST be reported together with the total number of values. The context under which the sample is obtained, including the selected parameters, and the route traversed by the LSPs MUST also be reported. 3. One paragraph is added to 9.5, 10.5, 11.5, 12.5 and 13.5: It is important that in obtaining a sample all the LSPs MUST traverse the same route. Ways to realize this is outside the scope of this document. However, it is desirable that the method used have minimal impact on the signaling process and the method SHOULD be reported. 4. A bunch of non-technical changes. Best regards, Weiqiang -------------------------------------------------- From: Sent: Sunday, September 27, 2009 8:00 PM To: Cc: Subject: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-09.txt > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Common Control and Measurement Plane > Working Group of the IETF. > > > Title : Label Switched Path (LSP) Dynamic Provisioning > Performance Metrics in Generalized MPLS Networks > Author(s) : W. Sun, et al. > Filename : draft-ietf-ccamp-lsp-dppm-09.txt > Pages : 52 > Date : 2009-09-27 > > Generalized Multi-Protocol Label Switching (GMPLS) is one of the most > promising candidate technologies for future data transmission > network. GMPLS has been developed to control and operate different > kinds of network elements, such as conventional routers, switches, > Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop > Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- > connects (OXCs), etc. The dynamic provisioning ability of these > physically diverse devices differs from each other drastically. At > the same time, the need for dynamically provisioned connections is > increasing because optical networks are being deployed in metro > areas. As different applications have varied requirements in the > provisioning performance of optical networks, it is imperative to > define standardized metrics and procedures such that the performance > of networks and application needs can be mapped to each other. > > This document provides a series of performance metrics to evaluate > the dynamic LSP provisioning performance in GMPLS networks, > specifically the dynamic LSP setup/release performance. These > metrics can be used to characterize the features of GMPLS networks in > LSP dynamic provisioning. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-dppm-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 lberger@labn.net Sun Sep 27 06:31:22 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9028A3A67C1 for ; Sun, 27 Sep 2009 06:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.317 X-Spam-Level: X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpYf1gxht2tm for ; Sun, 27 Sep 2009 06:31:21 -0700 (PDT) Received: from outbound-mail-117.bluehost.com (outbound-mail-117.bluehost.com [69.89.22.17]) by core3.amsl.com (Postfix) with SMTP id B694C3A6969 for ; Sun, 27 Sep 2009 06:31:21 -0700 (PDT) Received: (qmail 22474 invoked by uid 0); 27 Sep 2009 13:32:27 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy3.bluehost.com with SMTP; 27 Sep 2009 13:32:27 -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=05kbE7yhw4sSlQWuct3eX5a9HvjppjlxCi+YS2pTg8i7qfS3NQkuQy32EkR3k4uwK5jhfxh7yslg+HU1XbI4TEbCPYdQT14W5paHBWWLdUYsQk+mrfoxeQXcVtqcj9Pw; 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 1MrtrX-0005Ge-AG; Sun, 27 Sep 2009 07:32:27 -0600 Message-ID: <4ABF697D.7040302@labn.net> Date: Sun, 27 Sep 2009 09:32:45 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Weiqiang Sun References: <20090927120002.28EB33A689E@core3.amsl.com> In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-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: Sun, 27 Sep 2009 13:31:22 -0000 On 9/27/2009 8:16 AM, Weiqiang Sun wrote: > >3. One paragraph is added to 9.5, 10.5, 11.5, 12.5 and 13.5: > It is important that in obtaining a sample all the LSPs MUST traverse > the same route. Ways to realize this is outside the scope of this > document. However, it is desirable that the method used have minimal > impact on the signaling process and the method SHOULD be reported. Weiqiang, A couple of question WRT the above paragraph: - Wouldn't use of the same paths be useful in cases 5 and 7 too? - Why not require the use of ERO (with RRO recording) to ensure the same route rather than say it's out of scope? Also, now that you have the Metric Reporting section, which I think is great, you don't need to say what must be reported in the discussion section. For example the text in 4.6 that says "and the value MUST be reported" is now redundant with 4.8, so should be dropped from 4.6. Lou From sunwq@MIT.EDU Sun Sep 27 06:43:48 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45DB3A69BC for ; Sun, 27 Sep 2009 06:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA7ci+Kaof5t for ; Sun, 27 Sep 2009 06:43:48 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id E99EA3A68D6 for ; Sun, 27 Sep 2009 06:43:47 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n8RDj0ME020910; Sun, 27 Sep 2009 09:45:00 -0400 (EDT) Received: from APC (84.155.38.58.broad.xw.sh.dynamic.163data.com.cn [58.38.155.84] (may be forged)) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n8RDiuqf029735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 27 Sep 2009 09:44:59 -0400 (EDT) Message-ID: From: "Weiqiang Sun" To: "Lou Berger" References: <20090927120002.28EB33A689E@core3.amsl.com> <4ABF697D.7040302@labn.net> In-Reply-To: <4ABF697D.7040302@labn.net> Date: Sun, 27 Sep 2009 21:44:51 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-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: Sun, 27 Sep 2009 13:43:48 -0000 Hi Lou, See below Please. -------------------------------------------------- From: "Lou Berger" Sent: Sunday, September 27, 2009 9:32 PM To: "Weiqiang Sun" Cc: Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-09.txt > On 9/27/2009 8:16 AM, Weiqiang Sun wrote: >> >>3. One paragraph is added to 9.5, 10.5, 11.5, 12.5 and 13.5: >> It is important that in obtaining a sample all the LSPs MUST traverse >> the same route. Ways to realize this is outside the scope of this >> document. However, it is desirable that the method used have minimal >> impact on the signaling process and the method SHOULD be reported. > > Weiqiang, > A couple of question WRT the above paragraph: > - Wouldn't use of the same paths be useful in cases 5 and 7 too? Yes, this should be added. > - Why not require the use of ERO (with RRO recording) to ensure the same > route rather than say it's out of scope? Yes the use of ERO may be good but not always necessary. For example, when linear topology is used (which is often used in fact), there is no need for including an ERO for the testing purpose. > > Also, now that you have the Metric Reporting section, which I think is > great, you don't need to say what must be reported in the discussion > section. For example the text in 4.6 that says "and the value MUST be > reported" is now redundant with 4.8, so should be dropped from 4.6. OK. > > Lou > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Sun Sep 27 06:49:23 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0192F3A6833 for ; Sun, 27 Sep 2009 06:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YX2M992-ipXC for ; Sun, 27 Sep 2009 06:49:22 -0700 (PDT) Received: from outbound-mail-14.bluehost.com (outbound-mail-14.bluehost.com [69.89.18.114]) by core3.amsl.com (Postfix) with SMTP id 158073A683D for ; Sun, 27 Sep 2009 06:49:22 -0700 (PDT) Received: (qmail 32698 invoked by uid 0); 27 Sep 2009 13:50:38 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy1.bluehost.com with SMTP; 27 Sep 2009 13:50:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=TlttPrvjOOab7RpQZueNfra8YRC92xqBqNFVR1OwutZOW8soFDVn90uBj8Y7szIb9D3EgCxczLy91njzYgT4p297DNvjkZX4veQn04qW02lNuI51WAzEvZArb/uY3+NZ; 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 1Mru97-0008US-Lf; Sun, 27 Sep 2009 07:50:37 -0600 Message-ID: <4ABF6DC0.3070504@labn.net> Date: Sun, 27 Sep 2009 09:50:56 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Weiqiang Sun References: <20090927120002.28EB33A689E@core3.amsl.com> <4ABF697D.7040302@labn.net> In-Reply-To: X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-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: Sun, 27 Sep 2009 13:49:23 -0000 Weiqiang, So why not say this + use ERO when needed? Also, use of RRO is required to report path, so should say this too. Lou On 9/27/2009 9:44 AM, Weiqiang Sun wrote: >> - Why not require the use of ERO (with RRO recording) to ensure the same >> route rather than say it's out of scope? > Yes the use of ERO may be good but not always necessary. For example, > when linear topology is used (which is often used in fact), there is no > need for including an ERO for the testing purpose. From sunwq@MIT.EDU Sun Sep 27 07:01:15 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327903A69B9 for ; Sun, 27 Sep 2009 07:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQT6aXsm9cqi for ; Sun, 27 Sep 2009 07:01:14 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 485613A68D6 for ; Sun, 27 Sep 2009 07:01:14 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n8RE2SN2027878; Sun, 27 Sep 2009 10:02:28 -0400 (EDT) Received: from APC (84.155.38.58.broad.xw.sh.dynamic.163data.com.cn [58.38.155.84] (may be forged)) (authenticated bits=0) (User authenticated as sunwq@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n8RE2OW3001104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 27 Sep 2009 10:02:26 -0400 (EDT) Message-ID: <33118BA1329448E180DAB02033B0ECCA@mit.edu> From: "Weiqiang Sun" To: "Lou Berger" References: <20090927120002.28EB33A689E@core3.amsl.com> <4ABF697D.7040302@labn.net> <4ABF6DC0.3070504@labn.net> In-Reply-To: <4ABF6DC0.3070504@labn.net> Date: Sun, 27 Sep 2009 22:02:20 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Scanned-By: MIMEDefang 2.42 Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-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: Sun, 27 Sep 2009 14:01:15 -0000 Lou, what about the text below? It is important that in obtaining a sample all the LSPs MUST traverse the same route. In case there may be multiple routes between the ingress node ID0 and egress node ID1, EROs can be used to ensure that all LSPs traverse the same route. In doing this, RROs may also be needed to record the route. Thanks, Weiqiang -------------------------------------------------- From: "Lou Berger" Sent: Sunday, September 27, 2009 9:50 PM To: "Weiqiang Sun" Cc: Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-09.txt > Weiqiang, > So why not say this + use ERO when needed? Also, use of RRO is > required to report path, so should say this too. > > Lou > > On 9/27/2009 9:44 AM, Weiqiang Sun wrote: >>> - Why not require the use of ERO (with RRO recording) to ensure the same >>> route rather than say it's out of scope? >> Yes the use of ERO may be good but not always necessary. For example, >> when linear topology is used (which is often used in fact), there is no >> need for including an ERO for the testing purpose. > From lberger@labn.net Sun Sep 27 07:32:22 2009 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E99028C0E5 for ; Sun, 27 Sep 2009 07:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=0.220, 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 KtL5kpAZOLuq for ; Sun, 27 Sep 2009 07:32:21 -0700 (PDT) Received: from outbound-mail-14.bluehost.com (outbound-mail-14.bluehost.com [69.89.18.114]) by core3.amsl.com (Postfix) with SMTP id 81AD63A6900 for ; Sun, 27 Sep 2009 07:32:21 -0700 (PDT) Received: (qmail 25828 invoked by uid 0); 27 Sep 2009 14:33:37 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy1.bluehost.com with SMTP; 27 Sep 2009 14:33:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Gfk3WWPVYrg46mzor262qEOrvZauco3vx+qKgGAWu7rKmtQO4bpjzzBZHnEpYZufN8ljYmrZS//iGm0CPCCfWDg+6z1yO7lCHr55rIHOn3qkRKs2oYaT/bNiR01BTSTs; 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 1Mruoj-0007x7-G3; Sun, 27 Sep 2009 08:33:37 -0600 Message-ID: <4ABF77D4.20801@labn.net> Date: Sun, 27 Sep 2009 10:33:56 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Weiqiang Sun References: <20090927120002.28EB33A689E@core3.amsl.com> <4ABF697D.7040302@labn.net> <4ABF6DC0.3070504@labn.net> <33118BA1329448E180DAB02033B0ECCA@mit.edu> In-Reply-To: <33118BA1329448E180DAB02033B0ECCA@mit.edu> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-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: Sun, 27 Sep 2009 14:32:22 -0000 Weiqiang, I think I wasn't clear that there are two points here: On 9/27/2009 10:02 AM, Weiqiang Sun wrote: > Lou, what about the text below? > > It is important that in obtaining a sample all the LSPs MUST traverse > the same route. In case there may be multiple routes between the ingress > node ID0 and egress node ID1, EROs can be used to ensure that all LSPs > traverse the same route. Shouldn't it be "MUST be used" rather than "can be used"? > In doing this, RROs may also be needed to record > the route. > My comment on RROs relate to the text in the document that says: "The route that the LSP tranverses MUST also be reported." To me this means that "an RRO MUST be included" when "the ingress node, forms the Path message". (Methodologies sections.) Lou > Thanks, > Weiqiang > > > -------------------------------------------------- > From: "Lou Berger" > Sent: Sunday, September 27, 2009 9:50 PM > To: "Weiqiang Sun" > Cc: > Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-lsp-dppm-09.txt > >> Weiqiang, >> So why not say this + use ERO when needed? Also, use of RRO is >> required to report path, so should say this too. >> >> Lou >> >> On 9/27/2009 9:44 AM, Weiqiang Sun wrote: >>>> - Why not require the use of ERO (with RRO recording) to ensure the >>>> same >>>> route rather than say it's out of scope? >>> Yes the use of ERO may be good but not always necessary. For example, >>> when linear topology is used (which is often used in fact), there is no >>> need for including an ERO for the testing purpose. >> > > >