From db3546@att.com Tue Feb 1 12:41:22 2011 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 9AB973A6C7A for ; Tue, 1 Feb 2011 12:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 hjRYyL1D4oNs for ; Tue, 1 Feb 2011 12:41:22 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id D5C593A6C5E for ; Tue, 1 Feb 2011 12:41:13 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-15.tower-146.messagelabs.com!1296593070!31707684!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 16725 invoked from network); 1 Feb 2011 20:44:30 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Feb 2011 20:44:30 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p11KhbfM027382 for ; Tue, 1 Feb 2011 15:43:37 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p11KhU7k027263 for ; Tue, 1 Feb 2011 15:43:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Feb 2011 15:44:21 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed ITU SG15 Liaison on G.709 Thread-Index: AcvCUM1wMlmdM7iSSZufkisLsO30/g== From: "BRUNGARD, DEBORAH A (ATTSI)" To: "CCAMP" Subject: [CCAMP] Proposed ITU SG15 Liaison on G.709 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 Feb 2011 20:41:22 -0000 CCAMP, We owe SG15 a liaison on G.709. Here's our proposal: ------------------------------------------------- Title: Response on G.709 efforts in ITU-T We thank you for your liaison statements, "COM 15 - LS 201 - E" and "COM 15-LS 221 - E" on G.709 efforts in ITU-T in regards to the use of transitional links in your OTN network architecture work. We are continuing to progress the OTN work items and we will take into consideration your work. Please keep us informed as you progress your work. We encourage those with interest in the protocol development to participate in our activities. The latest status can be found here: http://tools.ietf.org/wg/ccamp/ We look forward to continuing our cooperative relationship with you on these topics. ------------------------------------------- Let us know if any comments- Deborah and Lou From adrian@olddog.co.uk Tue Feb 1 13:06:23 2011 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 493733A6DEA for ; Tue, 1 Feb 2011 13:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 nA8eHYSWEfNb for ; Tue, 1 Feb 2011 13:06:21 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 1E2213A6C75 for ; Tue, 1 Feb 2011 13:06:05 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p11L9Giw026230; Tue, 1 Feb 2011 21:09:19 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p11L9C48026215; Tue, 1 Feb 2011 21:09:13 GMT From: "Adrian Farrel" To: Date: Tue, 1 Feb 2011 21:09:11 -0000 Message-ID: <081601cbc254$49677730$dc366590$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AcvCVDNrg4vPYpJZSouUhN9Mxs/MsA== Cc: 'CCAMP' , ccamp-chairs@tools.ietf.org, Dimitri.Papadimitriou@alcatel-lucent.com Subject: [CCAMP] Routing Directorate:Review of draft-ietf-ccamp-rwa-wson-framework X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 21:06:23 -0000 Hi authors of draft-ietf-ccamp-rwa-wson-framework, Here is the Routing Directorate review of your draft. Dimitri sent it into the ADs during the IETF last call period, and I would appreciate you handling the comments as if they were last call comments. Most of his points look pretty sound to me, so I think you will need to do another revision. Many thanks, Adrian > -----Original Message----- > From: Papadimitriou, Dimitri (Dimitri) [mailto:dimitri.papadimitriou@alcatel- > lucent.com] > Sent: 31 January 2011 23:42 > To: dbrungard@att.com > Cc: danli@huawei.com; adrian.farrel@huawei.com; stbryant@cisco.com > Subject: RE: [Rtg Area Wiki] #49 (waiting): Review of draft-ietf-ccamp-rwa-wson- > framework > > Hi, > > Here below my review of this document: > > o) Section 1. Introduction > > . State the actual issue(s) when applying current GMPLS (RFC X,Y,Z) to > wavelength switched networks to initiate such "framework" otherwise one could > think of a BCP > > . RFC 3945 mention support of wavelength/lambda switching is that different > from WSON ? or is the second a special case of the former (note this is how the > terminology section reads). > > . "In order to provision an optical connection (an optical path) through > a WSON certain path continuity and resource availability constraints > must be met to determine viable and optimal paths through the network." > > I will come back to this latter but the term "network" is to be qualified in context > of this document. In particular, afaik aren't there different specifications of IaDI > and IrDI interfaces. > > . "Note that this document focuses on the generic properties of links, > switches and path selection constraints that occur in WSONs." > > in which sense the term "generic" is used in this statement (usually considered > as application to multiple switching technologies) > > The main comment concerning this introduction is that the "motivation" (what's > the problem) and "positioning" (how it positions ?) shall be clarified. > > o) Section 3.1 > > . " The number of channels is > significantly smaller than the 32 bit GMPLS label space defined for > GMPLS, see [RFC3471]. A label representation for these ITU-T grids > is given in [Otani] and provides a common label format to be used in > signaling optical paths. " > > This falls into a Section describing (C)WDM links. It would be appropriate to move > such material into a sub-section describing the corresponding GMPLS/link > capabilities. The same remark applies to Section 3.2 and 3.3: it would be > appropriate to have a sub-section dedicated to the implication on the control > plane (first) and then to GMPLS protocols. > > o) Section 3.2 > > . Transmitter failure isn't specific to "WSON" but implications are the same or not > ? If a DXC transmitter fails clearly the node shall select another outgoing > interface. > > . "Hence, additional mechanisms > may be necessary to detect and differentiate this failure from the > others, e.g., one doesn't not want to initiate mesh restoration if > the source transmitter has failed, since the optical transmitter will > still be failed on the alternate optical path." > > This example is rather confusing, if a source transmitter fails of course selecting a > path along that transmitter won't work. > > o) Section 3.3 > > . "Note that a number of non-standard or proprietary modulation formats > and FEC codes are commonly used in WSONs. For some digital bit > streams the presence of Forwarding Equivalence Class (FEC) can be > detected, e.g., in [G.707] this is indicated in the signal itself via > the FEC Status Indication (FSI) byte, while in [G.709] this can be > inferred from whether the FEC field of the Optical Channel Transport > Unit-k (OTUk) is all zeros or not." > > Please indicate the impact at the control plane level, and GMPLS protocol level. > > o) Section 3.4 > > . "Only a subset of these and their non-impairment related properties > are considered in the following sections." > > How that subset has been selected ? Why not the full set ? Does it mean that the > GMPLS capabilities will only apply to this subset ? > > . "As the degree of the > ROADM increases beyond two it can have properties of both a switch > (OXC) and a multiplexer and hence it is necessary to know the > switched connectivity offered by such a network element to > effectively utilize it. " > > These constraints are equivalent to link administrative coloring with combinatorial > combination that can be encoded in their mask. I am not stating this would be > more effective than the proposed bit maps but how these constraint differs from > a MT routing when constraints are induced by node structure or topological > considerations. > > o) Section 3.4.2. and 3.4.3 > > . Are combiners and splitters also controlled by means of GMPLS. Splitter have > "fixed connectivity matrix" what is then the role of GMPLS / control plane ? > > . Same question applies for combiners. > > . The side question how hybrid environment would operate (e.g. GMPLS/OXC > with non-GMPLS splitters or combiners) > > o) Section 3.4.4 on Fixed Optical Add/Drop Multiplexers appears as a particular > case of ROADMs not sure whether the need a dedicated sub-section > > o) Section 3.5 > > . A definition of "transparency" would be more than welcome to understand the > remaining part of this sub-section > > . The statement "they can be more or less "transparent" to an "optical signal" > depending on their functionality and/or implementation." should be clarified > > o) Section 3.5.1 > > . States "What this table also shows by its omission is that no switching or > multiplexing occurs at this layer." the "this" refers to ? > > o) Section 3.5.2 > > . This section speaks more about regenerators than OEO (whereas this Section > entitled OEO Switches). The relationship between OEO and regeneration isn't > explicit from the text and should be outlined to ease understanding/readability > of this part of the document. > > o) Section 3.6 > > . " In WSONs where wavelength converters are sparse an optical path may > appear to loop or "backtrack" upon itself in order to reach a > wavelength converter prior to continuing on to its destination." > > There is a point to clarify here. A physical constraint would generate a loop that > can only be detected by means of RRO (but it is receiver which breaks the loop > not the sender). > > o) Section 3.6.1 > > . It seems from its description that a conversion pool is a particular case of use of > adjustment descriptor defined in RFC 6001 (that is a general mean to associate > resource pools to SC). > > o) Section 4 > > . From the description can authors confirm/infirm whether this framework > applies to a single "TE domain" thus in practice a single routing area ? or not ? > > . "It is to be noted that the choice of specific RWA algorithm is out of > the scope for this document" > > The more fundamental question is whether all RWA algorithms can be covered > or not by a single set of non-contending extensions/mechanisms or not; this > point is to be clarified as whether the proposed framework is "generic" or further > specialisation is still to be expected ? > > . Worth mentioning that the RWA problem is NP Complete. Thus "optimality" > should more carefully qualified here. More importantly (in the context of this > document) which level of sub-optimality is considered as acceptable in terms of > first rejection/retrial and second rejection/retrial this would provide nice bounds > on what the control suite should deliver (taking into account what it is capable to > deliver). > > o) Section 4.1.3 > > . It is required to distinguish signaling of unidirectional vs bidirectional path and > emphasize that the issue it is the upstream assignment in bi-dir LSP which is > issuing blocking not the downstream label one (indeed on the downstream > direction label assignment can't be blocking in terms of continuity otherwise > there no wavelength left for such assignment). The true problem is the upstream > label assignment and the error issued (cf. Acceptable Label Set) never sorted out > actually -- just for the record: upstream-labelset-00> ;-) > > o) Section 4.2 > > . "Utilize incremental updates if feasible." of which information assuming one > refers to routing information here ? are incremental updates intended to > decrease the number of state updates or the rate of updates ? > > o) Section 5.2 > > . "The calculation of optical impairment feasible routes is outside the > scope of this document. In general impairment feasible routes serve > as an input to RWA algorithm. > > It is advisable to qualify what is an "impairment" vs "optical impairment" against > a constraint induced by regeneration, conversion used to elevate these > impairments. > > o) Section 6.2.1 > > . " 4. Acceptable G-PID list: a list of G-PIDs corresponding to the > "client" digital streams that is compatible with this device." > > Why is this a problem when "client devices" (e.g. routers in Fig.7) advertise their > G-PID (see RFC 4202). > > o) Section 6.2.3 > > . " 1. These are the per port wavelength restrictions of an optical > device such as a ROADM and are independent of any optical > constraints imposed by a fiber link." > > The term "per port" seems to contradict the description and the actual attribute > association. See also above comment concerning this "restriction". > > . "4. Not necessarily needed in the case of distributed wavelength > assignment via signaling." > > The fundamental question isn't answered the combined RWA and separate RWA > are by definition centralized and global approaches (the computing node has > complete topology information and computes all paths even those for which it > isn't the source) -> why delocalizing them on each node makes the assumption > that the information exchange should de-facto rely on "link-state routing" (the > question isn't whether RWA needs this information or not, it does); on this point, > there is an interesting discussion initiated on bullet 4, Section 4.2 but it seems > that alternatives weren't considered at the end. Not the intention here to > remove or to preclude that option but ask to document/motivate the proposed > selection in the context of this framework. > > o) Other remarks > > . There is no discussion about contention resolution in case of concurrency among > requests, MBB applicability, and use of LMP (is the latter not foreseen or not > usable in the WSON context ?). > > . Understanding that minimizing the number of re-trials/crankback is a reasonable > goal; however, the question of extensions to crankback RFC and related that will > be needed in case of multiple concurrent requests isn't discussed at all e.g. > should the retry go back to the source or to intermediate nodes ? in which > conditions ? etc. > > Thanks, > -dimitri. > > > > > -----Original Message----- > > From: Rtg Area Wiki [mailto:trac@tools.ietf.org] > > Sent: Wednesday, January 19, 2011 12:12 AM > > To: Papadimitriou, Dimitri (Dimitri); dbrungard@att.com > > Cc: danli@huawei.com; adrian.farrel@huawei.com; stbryant@cisco.com > > Subject: Re: [Rtg Area Wiki] #49 (waiting): Review of > > draft-ietf-ccamp-rwa-wson-framework > > > > #49: Review of draft-ietf-ccamp-rwa-wson-framework > > > > Changes (by dbrungard@...): > > > > * cc: adrian.farrel@..., stbryant@... (added) > > * owner: dbrungard@... => dimitri.papadimitriou@... > > * status: open => waiting > > > > > > Old description: > > > > > > > > New description: > > > > By 2/1. > > > > -- > > > > -- > > ------------------------------+------------------------------- > > -------------- > > Reporter: dbrungard@... | Owner: > > dimitri.papadimitriou@... > > Type: review | Status: waiting > > > > Priority: major | Version: > > > > Keywords: wson gmpls | Draft: > > draft-ietf-ccamp-rwa-wson-framework > > ------------------------------+------------------------------- > > -------------- > > > > Ticket URL: > > > > Rtg Area Wiki > > > > = From wwwrun@rfc-editor.org Wed Feb 2 20:01:24 2011 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 A83E43A67EC; Wed, 2 Feb 2011 20:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.008 X-Spam-Level: X-Spam-Status: No, score=-102.008 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wnRte9C7Tq8; Wed, 2 Feb 2011 20:01:23 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 502D13A67EE; Wed, 2 Feb 2011 20:01:09 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E2F73E0749; Wed, 2 Feb 2011 20:04:30 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110203040430.E2F73E0749@rfc-editor.org> Date: Wed, 2 Feb 2011 20:04:30 -0800 (PST) Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org Subject: [CCAMP] RFC 6107 on Procedures for Dynamically Signaled Hierarchical Label Switched Paths 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 Feb 2011 04:01:24 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6107 Title: Procedures for Dynamically Signaled Hierarchical Label Switched Paths Author: K. Shiomoto, Ed., A. Farrel, Ed. Status: Standards Track Stream: IETF Date: February 2011 Mailbox: shiomoto.kohei@lab.ntt.co.jp, adrian@olddog.co.uk Pages: 30 Characters: 65363 Updates: RFC3477, RFC4206 I-D Tag: draft-ietf-ccamp-lsp-hierarchy-bis-08.txt URL: http://www.rfc-editor.org/rfc/rfc6107.txt Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks. Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process. [STANDARDS-TRACK] This document is a product of the Common Control and Measurement Plane Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From gregb@grotto-networking.com Thu Feb 3 14:14:41 2011 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 7A8AC3A6B1B for ; Thu, 3 Feb 2011 14:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.448, 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 yB-HM6eAC6pO for ; Thu, 3 Feb 2011 14:14:26 -0800 (PST) Received: from mail16c40.carrierzone.com (mail16c40.carrierzone.com [209.235.156.156]) by core3.amsl.com (Postfix) with ESMTP id 6C8893A6B25 for ; Thu, 3 Feb 2011 14:14:23 -0800 (PST) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.125] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail16c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id p13MHbnE016770; Thu, 3 Feb 2011 22:17:39 GMT Message-ID: <4D4B297F.4070701@grotto-networking.com> Date: Thu, 03 Feb 2011 14:17:35 -0800 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <081601cbc254$49677730$dc366590$@olddog.co.uk> In-Reply-To: <081601cbc254$49677730$dc366590$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------020601030702030009090505" X-CSC: 0 X-CHA: v=1.1 cv=VQ7YUjtfGgr3GAr4wX7pPypQ/B91NkanIee6Jm9vkWs= c=1 sm=1 a=3fpuP-AUP0sA:10 a=OkPnmgdRXU7//wtL+yd+jg==:17 a=Rg5jOeRUAAAA:8 a=zQP7CpKOAAAA:8 a=i0EeH86SAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=WgmKk6h_fnJvEVbS11kA:9 a=eqlRcHI-of_C7TngPB0A:7 a=rjUdJiAb4WxOqhO-Q6FHVDGZoIIA:4 a=wPNLvfGTeEIA:10 a=EgY3od2ZU2QA:10 a=h-I_03WOSDMA:10 a=IcfWiavFb3IA:10 a=Hz7IrDYlS0cA:10 a=hPjdaMEvmhQA:10 a=JfD0Fch1gWkA:10 a=y3TJSivtp0wihhKz:21 a=Rzk26ovQx108ferX:21 a=AEDFM0qtAAAA:8 a=4uh6ICFhx1-utabIir4A:9 a=cEBVVLqYX5FZDS2uvMcA:7 a=9RhlKVjU7JlfeLp37RvTOp5V6_YA:4 a=saJ1B4X3BoEA:10 a=jqlaW5bC1iAA:10 a=OkPnmgdRXU7//wtL+yd+jg==:117 Cc: draft-ietf-ccamp-rwa-wson-framework@tools.ietf.org, ccamp-chairs@tools.ietf.org, 'CCAMP' , Dimitri.Papadimitriou@alcatel-lucent.com Subject: Re: [CCAMP] Routing Directorate:Review of draft-ietf-ccamp-rwa-wson-framework 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 Feb 2011 22:14:41 -0000 This is a multi-part message in MIME format. --------------020601030702030009090505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for the review. Please see comments below and confirm agreement on proposed actions before we make changes to the document. Greg & Young On 2/1/2011 1:09 PM, Adrian Farrel wrote: > Hi authors of draft-ietf-ccamp-rwa-wson-framework, > > Here is the Routing Directorate review of your draft. Dimitri sent it into the > ADs during the IETF last call period, and I would appreciate you handling the > comments as if they were last call comments. > > Most of his points look pretty sound to me, so I think you will need to do > another revision. > > Many thanks, > Adrian > >> -----Original Message----- >> From: Papadimitriou, Dimitri (Dimitri) [mailto:dimitri.papadimitriou@alcatel- >> lucent.com] >> Sent: 31 January 2011 23:42 >> To: dbrungard@att.com >> Cc: danli@huawei.com; adrian.farrel@huawei.com; stbryant@cisco.com >> Subject: RE: [Rtg Area Wiki] #49 (waiting): Review of > draft-ietf-ccamp-rwa-wson- >> framework >> >> Hi, >> >> Here below my review of this document: >> >> o) Section 1. Introduction >> >> . State the actual issue(s) when applying current GMPLS (RFC X,Y,Z) to >> wavelength switched networks to initiate such "framework" otherwise one could >> think of a BCP --> The fundamental new issues raised are: (a) asymmetry of switching nodes, (b) RWA control plane architectural alternatives (particularly including PCE), (c) optical signal compatibility (for path selection). The detailed comparison to specific GMPLS RFCs are given in section 6, however we can add a paragraph or two of summary text to the introduction. >> . RFC 3945 mention support of wavelength/lambda switching is that different >> from WSON ? or is the second a special case of the former (note this is how > the >> terminology section reads). --> All "GMPLS" applications fall under the general description provided by RFC3945. The wavelength/lambda switching of RFC3945 is very general, in this document we rigorize the notions with the definition of optical signals in section 3.3 (based on ITU-T definitions). This helps clarify the use of amplifiers and regenerators and their implications for the control plane. --> can add text to introduction clarifying relation to RFC3945. >> . "In order to provision an optical connection (an optical path) through >> a WSON certain path continuity and resource availability constraints >> must be met to determine viable and optimal paths through the network." >> >> I will come back to this latter but the term "network" is to be qualified in > context >> of this document. In particular, afaik aren't there different specifications > of IaDI >> and IrDI interfaces. --> suggest changing "network" to "optical subnetwork". >> . "Note that this document focuses on the generic properties of links, >> switches and path selection constraints that occur in WSONs." >> >> in which sense the term "generic" is used in this statement (usually > considered >> as application to multiple switching technologies) >> >> The main comment concerning this introduction is that the "motivation" (what's >> the problem) and "positioning" (how it positions ?) shall be clarified. --> "Generic" in the sense of those properties of optical networks found across different contexts such as access, metro, and long haul. --> Suggest changing order of last two sentences of last paragraph of introduction. >> o) Section 3.1 >> >> . " The number of channels is >> significantly smaller than the 32 bit GMPLS label space defined for >> GMPLS, see [RFC3471]. A label representation for these ITU-T grids >> is given in [Otani] and provides a common label format to be used in >> signaling optical paths. " >> >> This falls into a Section describing (C)WDM links. It would be appropriate to > move >> such material into a sub-section describing the corresponding GMPLS/link >> capabilities. The same remark applies to Section 3.2 and 3.3: it would be >> appropriate to have a sub-section dedicated to the implication on the control >> plane (first) and then to GMPLS protocols. --> This document has been through numerous revisions and last calls and its present structure represents working group consensus. Would not recommend the proposed restructuring at this point in time. >> o) Section 3.2 >> >> . Transmitter failure isn't specific to "WSON" but implications are the same > or not >> ? If a DXC transmitter fails clearly the node shall select another outgoing >> interface. --> Your statement is true for a digital cross connect. However for a transparent network the problem would be with the source node and not the optical network. >> . "Hence, additional mechanisms >> may be necessary to detect and differentiate this failure from the >> others, e.g., one doesn't not want to initiate mesh restoration if >> the source transmitter has failed, since the optical transmitter will >> still be failed on the alternate optical path." >> >> This example is rather confusing, if a source transmitter fails of course > selecting a >> path along that transmitter won't work. --> See above comments. This text was suggested by another working group chair/AD. We could remove this entire discussion, but that may cause us trouble with a different chair/AD... >> o) Section 3.3 >> >> . "Note that a number of non-standard or proprietary modulation formats >> and FEC codes are commonly used in WSONs. For some digital bit >> streams the presence of Forwarding Equivalence Class (FEC) can be ==> error in text should be "Forward Error Correction" >> detected, e.g., in [G.707] this is indicated in the signal itself via >> the FEC Status Indication (FSI) byte, while in [G.709] this can be >> inferred from whether the FEC field of the Optical Channel Transport >> Unit-k (OTUk) is all zeros or not." >> >> Please indicate the impact at the control plane level, and GMPLS protocol > level. --> Will fix error in text. >> o) Section 3.4 >> >> . "Only a subset of these and their non-impairment related properties >> are considered in the following sections." >> >> How that subset has been selected ? Why not the full set ? Does it mean that > the >> GMPLS capabilities will only apply to this subset ? --> Will change text to read "only the subset of these relevant to the control plane". >> . "As the degree of the >> ROADM increases beyond two it can have properties of both a switch >> (OXC) and a multiplexer and hence it is necessary to know the >> switched connectivity offered by such a network element to >> effectively utilize it. " >> >> These constraints are equivalent to link administrative coloring with > combinatorial >> combination that can be encoded in their mask. I am not stating this would be >> more effective than the proposed bit maps but how these constraint differs > from >> a MT routing when constraints are induced by node structure or topological >> considerations. --> this statement is concerned with the connectivity capabilities of a switch which was modeled via the connectivity matrix mechanism. >> o) Section 3.4.2. and 3.4.3 >> >> . Are combiners and splitters also controlled by means of GMPLS. Splitter have >> "fixed connectivity matrix" what is then the role of GMPLS / control plane ? --> Fixed connectivity devices tend to be used in conjunction with switched devices. Hence their presence is crucial in determining paths. >> . Same question applies for combiners. --> See above. >> . The side question how hybrid environment would operate (e.g. GMPLS/OXC >> with non-GMPLS splitters or combiners) --> Would need to use the network management system. Out of our scope. >> o) Section 3.4.4 on Fixed Optical Add/Drop Multiplexers appears as a > particular >> case of ROADMs not sure whether the need a dedicated sub-section --> Suggest leaving the section. Since these are common in optical networks. >> o) Section 3.5 >> >> . A definition of "transparency" would be more than welcome to understand the >> remaining part of this sub-section >> >> . The statement "they can be more or less "transparent" to an "optical signal" >> depending on their functionality and/or implementation." should be clarified --> The definitions of the different levels of regenerators (from optical amplifiers to 3R) serves to illustrate the somewhat vague concept of "transparency". There is no formal definition of "transparency" and previous attempts to make one ran into difficulties (not defined by ITU-T, not clear what this would mean when nonlinearities are introduced). >> o) Section 3.5.1 >> >> . States "What this table also shows by its omission is that no switching or >> multiplexing occurs at this layer." the "this" refers to ? --> Will change text to read "What table 2 also shows..." >> o) Section 3.5.2 >> >> . This section speaks more about regenerators than OEO (whereas this Section >> entitled OEO Switches). The relationship between OEO and regeneration isn't >> explicit from the text and should be outlined to ease > understanding/readability >> of this part of the document. --> Suggest rearranging order of sentences 2 and 3 of this paragraph and rewording a bit to make functionality of OEO switches and their relation to regeneration clearer. >> o) Section 3.6 >> >> . " In WSONs where wavelength converters are sparse an optical path may >> appear to loop or "backtrack" upon itself in order to reach a >> wavelength converter prior to continuing on to its destination." >> >> There is a point to clarify here. A physical constraint would generate a loop > that >> can only be detected by means of RRO (but it is receiver which breaks the loop >> not the sender). >> --> Yes. No change to text seems indicated. >> o) Section 3.6.1 >> >> . It seems from its description that a conversion pool is a particular case of > use of >> adjustment descriptor defined in RFC 6001 (that is a general mean to associate >> resource pools to SC). --> This is similar in concept, except we are not treating this as a MLN/MRN problem but as a single layer since there is essentially only one level of switching capability. >> o) Section 4 >> >> . From the description can authors confirm/infirm whether this framework >> applies to a single "TE domain" thus in practice a single routing area ? or > not ? --> This document does not address multiple AS issues. >> . "It is to be noted that the choice of specific RWA algorithm is out of >> the scope for this document" >> >> The more fundamental question is whether all RWA algorithms can be covered >> or not by a single set of non-contending extensions/mechanisms or not; this >> point is to be clarified as whether the proposed framework is "generic" or > further >> specialisation is still to be expected ? --> There are RWA techniques (not purely algorithms) that utilize distributed mechanisms that do not fit with the GMPLS/PCE signaling and routing paradigm. However, the combined RWA architecture of 4.1.1 can support any algorithm by definition. No further specialization is expected. >> . Worth mentioning that the RWA problem is NP Complete. Thus "optimality" >> should more carefully qualified here. More importantly (in the context of this >> document) which level of sub-optimality is considered as acceptable in terms > of >> first rejection/retrial and second rejection/retrial this would provide nice > bounds >> on what the control suite should deliver (taking into account what it is > capable to >> deliver). --> Previous editions of this document pointed out the complexity of the RWA problem and to surveys such as [1] H. Zang, J. Jue, and B. Mukherjeee, "A review of routing and wavelength assignment approaches for wavelength-routed optical WDM networks," Optical Networks Magazine, 2000. that show the types algorithms and situations that can arise. Such information was removed at the request of WG chairs and/or ADs. >> o) Section 4.1.3 >> >> . It is required to distinguish signaling of unidirectional vs bidirectional > path and >> emphasize that the issue it is the upstream assignment in bi-dir LSP which is >> issuing blocking not the downstream label one (indeed on the downstream >> direction label assignment can't be blocking in terms of continuity otherwise >> there no wavelength left for such assignment). The true problem is the > upstream >> label assignment and the error issued (cf. Acceptable Label Set) never sorted > out >> actually -- just for the record:> upstream-labelset-00> ;-) --> acknowledged. >> o) Section 4.2 >> >> . "Utilize incremental updates if feasible." of which information assuming one >> refers to routing information here ? are incremental updates intended to >> decrease the number of state updates or the rate of updates ? --> "incremental" updates of link information, particularly available bandwidth. Can remove this statement if desired. >> o) Section 5.2 >> >> . "The calculation of optical impairment feasible routes is outside the >> scope of this document. In general impairment feasible routes serve >> as an input to RWA algorithm. >> >> It is advisable to qualify what is an "impairment" vs "optical impairment" > against >> a constraint induced by regeneration, conversion used to elevate these >> impairments. ==> Error in text. All impairments we are talking about are optical. Will insert the word "optical". >> o) Section 6.2.1 >> >> . " 4. Acceptable G-PID list: a list of G-PIDs corresponding to the >> "client" digital streams that is compatible with this device." >> >> Why is this a problem when "client devices" (e.g. routers in Fig.7) advertise > their >> G-PID (see RFC 4202). --> This is a reminder that GPID can be important for optical networks too. Optical networks are not necessarily as "transparent" as people are led to believe. >> o) Section 6.2.3 >> >> . " 1. These are the per port wavelength restrictions of an optical >> device such as a ROADM and are independent of any optical >> constraints imposed by a fiber link." >> >> The term "per port" seems to contradict the description and the actual > attribute >> association. See also above comment concerning this "restriction". --> This statement is clarifying the difference between the source of the wavelength restriction (i.e. the ROADM versus the fiber). Can remove if desired. >> . "4. Not necessarily needed in the case of distributed wavelength >> assignment via signaling." >> >> The fundamental question isn't answered the combined RWA and separate RWA >> are by definition centralized and global approaches (the computing node has >> complete topology information and computes all paths even those for which it >> isn't the source) -> why delocalizing them on each node makes the assumption >> that the information exchange should de-facto rely on "link-state routing" > (the >> question isn't whether RWA needs this information or not, it does); on this > point, >> there is an interesting discussion initiated on bullet 4, Section 4.2 but it > seems >> that alternatives weren't considered at the end. Not the intention here to >> remove or to preclude that option but ask to document/motivate the proposed >> selection in the context of this framework. --> Alternatives along these lines were discussed at the PCE group but not adopted as a work item. >> o) Other remarks >> >> . There is no discussion about contention resolution in case of concurrency > among >> requests, MBB applicability, and use of LMP (is the latter not foreseen or not >> usable in the WSON context ?). --> Current mechanisms suffice for WSON, i.e., WSON isn't so different from SONET/SDH in this regard. >> . Understanding that minimizing the number of re-trials/crankback is a > reasonable >> goal; however, the question of extensions to crankback RFC and related that > will >> be needed in case of multiple concurrent requests isn't discussed at all e.g. >> should the retry go back to the source or to intermediate nodes ? in which >> conditions ? etc. --> Good question for PCE. Not specific to WSON. >> Thanks, >> -dimitri. >> >> >> >>> -----Original Message----- >>> From: Rtg Area Wiki [mailto:trac@tools.ietf.org] >>> Sent: Wednesday, January 19, 2011 12:12 AM >>> To: Papadimitriou, Dimitri (Dimitri); dbrungard@att.com >>> Cc: danli@huawei.com; adrian.farrel@huawei.com; stbryant@cisco.com >>> Subject: Re: [Rtg Area Wiki] #49 (waiting): Review of >>> draft-ietf-ccamp-rwa-wson-framework >>> >>> #49: Review of draft-ietf-ccamp-rwa-wson-framework >>> >>> Changes (by dbrungard@...): >>> >>> * cc: adrian.farrel@..., stbryant@... (added) >>> * owner: dbrungard@... => dimitri.papadimitriou@... >>> * status: open => waiting >>> >>> >>> Old description: >>> >>> >>> >>> New description: >>> >>> By 2/1. >>> >>> -- >>> >>> -- >>> ------------------------------+------------------------------- >>> -------------- >>> Reporter: dbrungard@... | Owner: >>> dimitri.papadimitriou@... >>> Type: review | Status: waiting >>> >>> Priority: major | Version: >>> >>> Keywords: wson gmpls | Draft: >>> draft-ietf-ccamp-rwa-wson-framework >>> ------------------------------+------------------------------- >>> -------------- >>> >>> Ticket URL: >>> >>> Rtg Area Wiki >>> >>> = > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------020601030702030009090505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for the review. Please see comments below and confirm agreement on proposed actions before we make changes to the document.

Greg & Young

On 2/1/2011 1:09 PM, Adrian Farrel wrote: 
Hi authors of draft-ietf-ccamp-rwa-wson-framework,

Here is the Routing Directorate review of your draft. Dimitri sent it into the
ADs during the IETF last call period, and I would appreciate you handling the
comments as if they were last call comments.

Most of his points look pretty sound to me, so I think you will need to do
another revision.

Many thanks,
Adrian


-----Original Message-----
From: Papadimitriou, Dimitri (Dimitri) [mailto:dimitri.papadimitriou@alcatel-
lucent.com]
Sent: 31 January 2011 23:42
To: dbrungard@att.com
Cc: danli@huawei.com; adrian.farrel@huawei.com; stbryant@cisco.com
Subject: RE: [Rtg Area Wiki] #49 (waiting): Review of

draft-ietf-ccamp-rwa-wson-

framework

Hi,

Here below my review of this document:

o) Section 1. Introduction

. State the actual issue(s) when applying current GMPLS (RFC X,Y,Z) to
wavelength switched networks to initiate such "framework" otherwise one could
think of a BCP
-->  The fundamental new issues raised are: (a) asymmetry of switching nodes, (b) RWA control plane architectural alternatives (particularly including PCE),  (c) optical signal compatibility (for path selection).

The detailed comparison to specific GMPLS RFCs are given in section 6, however we can add a paragraph or two of summary text to the introduction. 
. RFC 3945 mention support of wavelength/lambda switching is that different
from WSON ? or is the second a special case of the former (note this is how

the

terminology section reads).
--> All "GMPLS" applications fall under the general description provided by RFC3945. The wavelength/lambda switching of RFC3945 is very general, in this document we rigorize the notions with the definition of optical signals in section 3.3 (based on ITU-T definitions). This helps clarify the use of amplifiers and regenerators and their implications for the control plane.
--> can add text to introduction clarifying relation to RFC3945. 
. "In order to provision an optical connection (an optical path) through
a WSON certain path continuity and resource availability constraints
must be met to determine viable and optimal paths through the network."

I will come back to this latter but the term "network" is to be qualified in

context

of this document. In particular, afaik aren't there different specifications

of IaDI

and IrDI interfaces.
--> suggest changing "network" to "optical subnetwork". 
. "Note that this document focuses on the generic properties of links,
switches and path selection constraints that occur in WSONs."

  in which sense the term "generic" is used in this statement (usually

considered

as application to multiple switching technologies)

The main comment concerning this introduction is that the "motivation" (what's
the problem) and "positioning" (how it positions ?) shall be clarified.
-->  "Generic" in the sense of those properties of optical networks found across different contexts such as access, metro, and long haul.
--> Suggest changing order of last two sentences of last paragraph of introduction. 
o) Section 3.1

. " The number of channels is
   significantly smaller than the 32 bit GMPLS label space defined for
   GMPLS, see [RFC3471].  A label representation for these ITU-T grids
   is given in [Otani] and provides a common label format to be used in
   signaling optical paths. "

This falls into a Section describing (C)WDM links. It would be appropriate to

move

such material into a sub-section describing the corresponding GMPLS/link
capabilities. The same remark applies to Section 3.2 and 3.3: it would be
appropriate to have a sub-section dedicated to the implication on the control
plane (first) and then to GMPLS protocols.
--> This document has been through numerous revisions and last calls and its present structure represents working group consensus. Would not recommend the proposed restructuring at this point in time.
o) Section 3.2

. Transmitter failure isn't specific to "WSON" but implications are the same

or not

? If a DXC transmitter fails clearly the node shall select another outgoing
interface.
-->  Your statement is true for a digital cross connect. However for a transparent network the problem would be with the source node and not the optical network. 
. "Hence, additional mechanisms
   may be necessary to detect and differentiate this failure from the
   others, e.g., one doesn't not want to initiate mesh restoration if
   the source transmitter has failed, since the optical transmitter will
   still be failed on the alternate optical path."

This example is rather confusing, if a source transmitter fails of course

selecting a

path along that transmitter won't work.
--> See above comments. This text was suggested by another working group chair/AD. We could remove this entire discussion, but that may cause us trouble with a different chair/AD... 
o) Section 3.3

.  "Note that a number of non-standard or proprietary modulation formats
   and FEC codes are commonly used in WSONs. For some digital bit
   streams the presence of Forwarding Equivalence Class (FEC) can be
==> error in text should be "Forward Error Correction" 
   detected, e.g., in [G.707] this is indicated in the signal itself via
   the FEC Status Indication (FSI) byte, while in [G.709] this can be
   inferred from whether the FEC field of the Optical Channel Transport
   Unit-k (OTUk) is all zeros or not."

Please indicate the impact at the control plane level, and GMPLS protocol

level.
--> Will fix error in text. 
o) Section 3.4

. "Only a subset of these and their non-impairment related properties
   are considered in the following sections."

How that subset has been selected ? Why not the full set ? Does it mean that

the

GMPLS capabilities will only apply to this subset ?
--> Will change text to read "only the subset of these relevant to the control plane". 
. "As the degree of the
   ROADM increases beyond two it can have properties of both a switch
   (OXC) and a multiplexer and hence it is necessary to know the
   switched connectivity offered by such a network element to
   effectively utilize it. "

These constraints are equivalent to link administrative coloring with

combinatorial

combination that can be encoded in their mask. I am not stating this would be
more effective than the proposed bit maps but how these constraint differs

from

a MT routing when constraints are induced by node structure or topological
considerations.
--> this statement is concerned with the connectivity capabilities of a switch which was modeled via the connectivity matrix mechanism. 
o) Section 3.4.2. and 3.4.3

. Are combiners and splitters also controlled by means of GMPLS. Splitter have
"fixed connectivity matrix" what is then the role of GMPLS / control plane ?
--> Fixed connectivity devices tend to be used in conjunction with switched devices. Hence their presence is crucial in determining paths. 
. Same question applies for combiners.
--> See above. 
. The side question how hybrid environment would operate (e.g. GMPLS/OXC
with non-GMPLS splitters or combiners)
-->  Would need to use the network management system. Out of our scope. 
o) Section 3.4.4 on Fixed Optical Add/Drop Multiplexers appears as a

particular

case of ROADMs not sure whether the need a dedicated sub-section
-->  Suggest leaving the section. Since these are common in optical networks. 
o) Section 3.5

. A definition of "transparency" would be more than welcome to understand the
remaining part of this sub-section

. The statement "they can be more or less "transparent" to an "optical signal"
depending on their functionality and/or implementation." should be clarified
-->  The definitions of the different levels of regenerators (from optical amplifiers to 3R) serves to illustrate the somewhat vague concept of "transparency".  There is no formal definition of "transparency" and previous attempts to make one ran into difficulties (not defined by ITU-T, not clear what this would mean when nonlinearities are introduced). 
o) Section 3.5.1

. States "What this table also shows by its omission is that no switching or
multiplexing occurs at this layer." the "this" refers to ?
--> Will change text to read "What table 2 also shows..." 
o) Section 3.5.2

. This section speaks more about regenerators than OEO (whereas this Section
entitled OEO Switches). The relationship between OEO and regeneration isn't
explicit from the text and should be outlined to ease

understanding/readability

of this part of the document.
-->  Suggest rearranging order of sentences 2 and 3 of this paragraph and rewording a bit to make functionality of OEO switches and their relation to regeneration clearer. 
o) Section 3.6

. " In WSONs where wavelength converters are sparse an optical path may
   appear to loop or "backtrack" upon itself in order to reach a
   wavelength converter prior to continuing on to its destination."

There is a point to clarify here. A physical constraint would generate a loop

that

can only be detected by means of RRO (but it is receiver which breaks the loop
not the sender).
--> Yes.  No change to text seems indicated. 
o) Section 3.6.1

. It seems from its description that a conversion pool is a particular case of

use of

adjustment descriptor defined in RFC 6001 (that is a general mean to associate
resource pools to SC).
--> This is similar in concept, except we are not treating this as a MLN/MRN problem but as a single layer since there is essentially only one level of switching capability. 
o) Section 4

. From the description can authors confirm/infirm whether this framework
applies to a single "TE domain" thus in practice a single routing area ? or

not ?

--> This document does not address multiple AS issues. 
. "It is to be noted that the choice of specific RWA algorithm is out of
   the scope for this document"

  The more fundamental question is whether all RWA algorithms can be covered
or not by a single set of non-contending extensions/mechanisms or not; this
point is to be clarified as whether the proposed framework is "generic" or

further

specialisation is still to be expected ?
-->  There are RWA techniques (not purely algorithms) that utilize distributed mechanisms that do not fit with the GMPLS/PCE signaling and routing paradigm.  However, the combined RWA architecture of 4.1.1 can support any algorithm by definition.  No further specialization is expected. 
. Worth mentioning that the RWA problem is NP Complete. Thus "optimality"
should more carefully qualified here. More importantly (in the context of this
document) which level of sub-optimality is considered as acceptable in terms

of

first rejection/retrial and second rejection/retrial this would provide nice

bounds

on what the control suite should deliver (taking into account what it is

capable to

deliver).
--> Previous editions of this document pointed out the complexity of the RWA problem and to surveys such as
[1] H. Zang, J. Jue, and B. Mukherjeee, “A review of routing and wavelength assignment approaches for wavelength-routed optical WDM networks,” Optical Networks Magazine, 2000.  
that show the types algorithms and situations that can arise. Such information was removed at the request of WG chairs and/or ADs. 
o) Section 4.1.3

. It is required to distinguish signaling of unidirectional vs bidirectional

path and

emphasize that the issue it is the upstream assignment in bi-dir LSP which is
issuing blocking not the downstream label one (indeed on the downstream
direction label assignment can't be blocking in terms of continuity otherwise
there no wavelength left for such assignment). The true problem is the

upstream

label assignment and the error issued (cf. Acceptable Label Set) never sorted

out

actually -- just for the record: <http://tools.ietf.org/html/draft-oki-ccamp-
upstream-labelset-00> ;-)
--> acknowledged. 
o) Section 4.2

. "Utilize incremental updates if feasible." of which information assuming one
refers to routing information here ? are incremental updates intended to
decrease the number of state updates or the rate of updates ?
--> "incremental" updates of link information, particularly available bandwidth. Can remove this statement if desired. 
o) Section 5.2

. "The calculation of optical impairment feasible routes is outside the
   scope of this document. In general impairment feasible routes serve
   as an input to RWA algorithm.

  It is advisable to qualify what is an "impairment" vs "optical impairment"

against

a constraint induced by regeneration, conversion used to elevate these
impairments.
==> Error in text. All impairments we are talking about are optical. Will insert the word "optical". 
o) Section 6.2.1

. "  4. Acceptable G-PID list: a list of G-PIDs corresponding to the
     "client" digital streams that is compatible with this device."

Why is this a problem when "client devices" (e.g. routers in Fig.7) advertise

their

G-PID (see RFC 4202).
-->  This is a reminder that GPID can be important for optical networks too.  Optical networks are not necessarily as "transparent" as people are led to believe. 
o) Section 6.2.3

. " 1. These are the per port wavelength restrictions of an optical
      device such as a ROADM and are independent of any optical
      constraints imposed by a fiber link."

The term "per port" seems to contradict the description and the actual

attribute

association. See also above comment concerning this "restriction".
--> This statement is clarifying the difference between the source of the wavelength restriction (i.e. the ROADM versus the fiber).  Can remove if desired. 
. "4. Not necessarily needed in the case of distributed wavelength
      assignment via signaling."

The fundamental question isn't answered the combined RWA and separate RWA
are by definition  centralized and global approaches (the computing node has
complete topology information and computes all paths even those for which it
isn't the source) -> why delocalizing them on each node makes the assumption
that the information exchange should de-facto rely on "link-state routing"

(the

question isn't whether RWA needs this information or not, it does); on this

point,

there is an interesting discussion initiated on bullet 4, Section 4.2 but it

seems

that alternatives weren't considered at the end. Not the intention here to
remove or to preclude that option but ask to document/motivate the proposed
selection in the context of this framework.
--> Alternatives along these lines were discussed at the PCE group but not adopted as a work item. 
o) Other remarks

. There is no discussion about contention resolution in case of concurrency

among

requests, MBB applicability, and use of LMP (is the latter not foreseen or not
usable in the WSON context ?).
--> Current mechanisms suffice for WSON, i.e., WSON isn't so different from SONET/SDH in this regard.
. Understanding that minimizing the number of re-trials/crankback is a

reasonable

goal; however, the question of extensions to crankback RFC and related that

will

be needed in case of multiple concurrent requests isn't discussed at all e.g.
should the retry go back to the source or to intermediate nodes ? in which
conditions ? etc.
--> Good question for PCE. Not specific to WSON. 
Thanks,
-dimitri.




-----Original Message-----
From: Rtg Area Wiki [mailto:trac@tools.ietf.org]
Sent: Wednesday, January 19, 2011 12:12 AM
To: Papadimitriou, Dimitri (Dimitri); dbrungard@att.com
Cc: danli@huawei.com; adrian.farrel@huawei.com; stbryant@cisco.com
Subject: Re: [Rtg Area Wiki] #49 (waiting): Review of
draft-ietf-ccamp-rwa-wson-framework

#49: Review of draft-ietf-ccamp-rwa-wson-framework

Changes (by dbrungard@...):

 * cc: adrian.farrel@..., stbryant@... (added)
  * owner:  dbrungard@... => dimitri.papadimitriou@...
  * status:  open => waiting


Old description:



New description:

 By 2/1.

--

--
------------------------------+-------------------------------
--------------
Reporter:  dbrungard@...        |     Owner:
dimitri.papadimitriou@...
    Type:  review             |    Status:  waiting

Priority:  major              |   Version:

Keywords:  wson gmpls         |     Draft:
draft-ietf-ccamp-rwa-wson-framework
------------------------------+-------------------------------
--------------

Ticket URL:
<http://trac.tools.ietf.org/area/rtg/trac/ticket/49#comment:2>
Rtg Area Wiki <http://tools.ietf.org/area/rtg/>

=





-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------020601030702030009090505-- From adrian@olddog.co.uk Fri Feb 4 04:14:40 2011 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 2E1DA3A6907 for ; Fri, 4 Feb 2011 04:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.082, 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 D9IzY+p-h3Vu for ; Fri, 4 Feb 2011 04:14:20 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by core3.amsl.com (Postfix) with ESMTP id 51DBE3A68E1 for ; Fri, 4 Feb 2011 04:14:19 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p14CHVu3006485; Fri, 4 Feb 2011 12:17:31 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p14CHRwX006452; Fri, 4 Feb 2011 12:17:28 GMT From: "Adrian Farrel" To: "'Greg Bernstein'" References: <081601cbc254$49677730$dc366590$@olddog.co.uk> <4D4B297F.4070701@grotto-networking.com> In-Reply-To: <4D4B297F.4070701@grotto-networking.com> Date: Fri, 4 Feb 2011 12:17:26 -0000 Message-ID: <0e4201cbc465$7f0cd700$7d268500$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E43_01CBC465.7F1D9FE0" X-Mailer: Microsoft Outlook 14.0 Content-language: en-gb Thread-index: AQFVC20gUVycFvihHkvawP/WjxdjDgJCtoqGlMydkzA= Cc: draft-ietf-ccamp-rwa-wson-framework@tools.ietf.org, ccamp-chairs@tools.ietf.org, 'CCAMP' , Dimitri.Papadimitriou@alcatel-lucent.com Subject: Re: [CCAMP] Routing Directorate:Review of draft-ietf-ccamp-rwa-wson-framework X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 12:14:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0E43_01CBC465.7F1D9FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi please go ahead with a new revision. Only point to note is "optical subnetwork". I advise against that as the term subnetwork has a very specific IETF meaning, and overloading it with ITU-T meaning is at best going to cause people to whinge. I think that whenever you say "network" you actually mean "WSON". You could throw that statement in up front, or you could search and replace network/WSON. Thanks for the work, Adrian From: Greg Bernstein [mailto:gregb@grotto-networking.com] Sent: 03 February 2011 22:18 To: adrian@olddog.co.uk Cc: draft-ietf-ccamp-rwa-wson-framework@tools.ietf.org; ccamp-chairs@tools.ietf.org; 'CCAMP'; Dimitri.Papadimitriou@alcatel-lucent.com Subject: Re: Routing Directorate:Review of draft-ietf-ccamp-rwa-wson-framework Thanks for the review. Please see comments below and confirm agreement on proposed actions before we make changes to the document. Greg & Young On 2/1/2011 1:09 PM, Adrian Farrel wrote: Hi authors of draft-ietf-ccamp-rwa-wson-framework, Here is the Routing Directorate review of your draft. Dimitri sent it into the ADs during the IETF last call period, and I would appreciate you handling the comments as if they were last call comments. Most of his points look pretty sound to me, so I think you will need to do another revision. Many thanks, Adrian -----Original Message----- From: Papadimitriou, Dimitri (Dimitri) [mailto:dimitri.papadimitriou@alcatel- lucent.com] Sent: 31 January 2011 23:42 To: dbrungard@att.com Cc: danli@huawei.com; adrian.farrel@huawei.com; stbryant@cisco.com Subject: RE: [Rtg Area Wiki] #49 (waiting): Review of draft-ietf-ccamp-rwa-wson- framework Hi, Here below my review of this document: o) Section 1. Introduction . State the actual issue(s) when applying current GMPLS (RFC X,Y,Z) to wavelength switched networks to initiate such "framework" otherwise one could think of a BCP --> The fundamental new issues raised are: (a) asymmetry of switching nodes, (b) RWA control plane architectural alternatives (particularly including PCE), (c) optical signal compatibility (for path selection). The detailed comparison to specific GMPLS RFCs are given in section 6, however we can add a paragraph or two of summary text to the introduction. . RFC 3945 mention support of wavelength/lambda switching is that different from WSON ? or is the second a special case of the former (note this is how the terminology section reads). --> All "GMPLS" applications fall under the general description provided by RFC3945. The wavelength/lambda switching of RFC3945 is very general, in this document we rigorize the notions with the definition of optical signals in section 3.3 (based on ITU-T definitions). This helps clarify the use of amplifiers and regenerators and their implications for the control plane. --> can add text to introduction clarifying relation to RFC3945. . "In order to provision an optical connection (an optical path) through a WSON certain path continuity and resource availability constraints must be met to determine viable and optimal paths through the network." I will come back to this latter but the term "network" is to be qualified in context of this document. In particular, afaik aren't there different specifications of IaDI and IrDI interfaces. --> suggest changing "network" to "optical subnetwork". . "Note that this document focuses on the generic properties of links, switches and path selection constraints that occur in WSONs." in which sense the term "generic" is used in this statement (usually considered as application to multiple switching technologies) The main comment concerning this introduction is that the "motivation" (what's the problem) and "positioning" (how it positions ?) shall be clarified. --> "Generic" in the sense of those properties of optical networks found across different contexts such as access, metro, and long haul. --> Suggest changing order of last two sentences of last paragraph of introduction. o) Section 3.1 . " The number of channels is significantly smaller than the 32 bit GMPLS label space defined for GMPLS, see [RFC3471]. A label representation for these ITU-T grids is given in [Otani] and provides a common label format to be used in signaling optical paths. " This falls into a Section describing (C)WDM links. It would be appropriate to move such material into a sub-section describing the corresponding GMPLS/link capabilities. The same remark applies to Section 3.2 and 3.3: it would be appropriate to have a sub-section dedicated to the implication on the control plane (first) and then to GMPLS protocols. --> This document has been through numerous revisions and last calls and its present structure represents working group consensus. Would not recommend the proposed restructuring at this point in time. o) Section 3.2 . Transmitter failure isn't specific to "WSON" but implications are the same or not ? If a DXC transmitter fails clearly the node shall select another outgoing interface. --> Your statement is true for a digital cross connect. However for a transparent network the problem would be with the source node and not the optical network. . "Hence, additional mechanisms may be necessary to detect and differentiate this failure from the others, e.g., one doesn't not want to initiate mesh restoration if the source transmitter has failed, since the optical transmitter will still be failed on the alternate optical path." This example is rather confusing, if a source transmitter fails of course selecting a path along that transmitter won't work. --> See above comments. This text was suggested by another working group chair/AD. We could remove this entire discussion, but that may cause us trouble with a different chair/AD... o) Section 3.3 . "Note that a number of non-standard or proprietary modulation formats and FEC codes are commonly used in WSONs. For some digital bit streams the presence of Forwarding Equivalence Class (FEC) can be ==> error in text should be "Forward Error Correction" detected, e.g., in [G.707] this is indicated in the signal itself via the FEC Status Indication (FSI) byte, while in [G.709] this can be inferred from whether the FEC field of the Optical Channel Transport Unit-k (OTUk) is all zeros or not." Please indicate the impact at the control plane level, and GMPLS protocol level. --> Will fix error in text. o) Section 3.4 . "Only a subset of these and their non-impairment related properties are considered in the following sections." How that subset has been selected ? Why not the full set ? Does it mean that the GMPLS capabilities will only apply to this subset ? --> Will change text to read "only the subset of these relevant to the control plane". . "As the degree of the ROADM increases beyond two it can have properties of both a switch (OXC) and a multiplexer and hence it is necessary to know the switched connectivity offered by such a network element to effectively utilize it. " These constraints are equivalent to link administrative coloring with combinatorial combination that can be encoded in their mask. I am not stating this would be more effective than the proposed bit maps but how these constraint differs from a MT routing when constraints are induced by node structure or topological considerations. --> this statement is concerned with the connectivity capabilities of a switch which was modeled via the connectivity matrix mechanism. o) Section 3.4.2. and 3.4.3 . Are combiners and splitters also controlled by means of GMPLS. Splitter have "fixed connectivity matrix" what is then the role of GMPLS / control plane ? --> Fixed connectivity devices tend to be used in conjunction with switched devices. Hence their presence is crucial in determining paths. . Same question applies for combiners. --> See above. . The side question how hybrid environment would operate (e.g. GMPLS/OXC with non-GMPLS splitters or combiners) --> Would need to use the network management system. Out of our scope. o) Section 3.4.4 on Fixed Optical Add/Drop Multiplexers appears as a particular case of ROADMs not sure whether the need a dedicated sub-section --> Suggest leaving the section. Since these are common in optical networks. o) Section 3.5 . A definition of "transparency" would be more than welcome to understand the remaining part of this sub-section . The statement "they can be more or less "transparent" to an "optical signal" depending on their functionality and/or implementation." should be clarified --> The definitions of the different levels of regenerators (from optical amplifiers to 3R) serves to illustrate the somewhat vague concept of "transparency". There is no formal definition of "transparency" and previous attempts to make one ran into difficulties (not defined by ITU-T, not clear what this would mean when nonlinearities are introduced). o) Section 3.5.1 . States "What this table also shows by its omission is that no switching or multiplexing occurs at this layer." the "this" refers to ? --> Will change text to read "What table 2 also shows..." o) Section 3.5.2 . This section speaks more about regenerators than OEO (whereas this Section entitled OEO Switches). The relationship between OEO and regeneration isn't explicit from the text and should be outlined to ease understanding/readability of this part of the document. --> Suggest rearranging order of sentences 2 and 3 of this paragraph and rewording a bit to make functionality of OEO switches and their relation to regeneration clearer. o) Section 3.6 . " In WSONs where wavelength converters are sparse an optical path may appear to loop or "backtrack" upon itself in order to reach a wavelength converter prior to continuing on to its destination." There is a point to clarify here. A physical constraint would generate a loop that can only be detected by means of RRO (but it is receiver which breaks the loop not the sender). --> Yes. No change to text seems indicated. o) Section 3.6.1 . It seems from its description that a conversion pool is a particular case of use of adjustment descriptor defined in RFC 6001 (that is a general mean to associate resource pools to SC). --> This is similar in concept, except we are not treating this as a MLN/MRN problem but as a single layer since there is essentially only one level of switching capability. o) Section 4 . From the description can authors confirm/infirm whether this framework applies to a single "TE domain" thus in practice a single routing area ? or not ? --> This document does not address multiple AS issues. . "It is to be noted that the choice of specific RWA algorithm is out of the scope for this document" The more fundamental question is whether all RWA algorithms can be covered or not by a single set of non-contending extensions/mechanisms or not; this point is to be clarified as whether the proposed framework is "generic" or further specialisation is still to be expected ? --> There are RWA techniques (not purely algorithms) that utilize distributed mechanisms that do not fit with the GMPLS/PCE signaling and routing paradigm. However, the combined RWA architecture of 4.1.1 can support any algorithm by definition. No further specialization is expected. . Worth mentioning that the RWA problem is NP Complete. Thus "optimality" should more carefully qualified here. More importantly (in the context of this document) which level of sub-optimality is considered as acceptable in terms of first rejection/retrial and second rejection/retrial this would provide nice bounds on what the control suite should deliver (taking into account what it is capable to deliver). --> Previous editions of this document pointed out the complexity of the RWA problem and to surveys such as [1] H. Zang, J. Jue, and B. Mukherjeee, "A review of routing and wavelength assignment approaches for wavelength-routed optical WDM networks," Optical Networks Magazine, 2000. that show the types algorithms and situations that can arise. Such information was removed at the request of WG chairs and/or ADs. o) Section 4.1.3 . It is required to distinguish signaling of unidirectional vs bidirectional path and emphasize that the issue it is the upstream assignment in bi-dir LSP which is issuing blocking not the downstream label one (indeed on the downstream direction label assignment can't be blocking in terms of continuity otherwise there no wavelength left for such assignment). The true problem is the upstream label assignment and the error issued (cf. Acceptable Label Set) never sorted out actually -- just for the record: > ;-) --> acknowledged. o) Section 4.2 . "Utilize incremental updates if feasible." of which information assuming one refers to routing information here ? are incremental updates intended to decrease the number of state updates or the rate of updates ? --> "incremental" updates of link information, particularly available bandwidth. Can remove this statement if desired. o) Section 5.2 . "The calculation of optical impairment feasible routes is outside the scope of this document. In general impairment feasible routes serve as an input to RWA algorithm. It is advisable to qualify what is an "impairment" vs "optical impairment" against a constraint induced by regeneration, conversion used to elevate these impairments. ==> Error in text. All impairments we are talking about are optical. Will insert the word "optical". o) Section 6.2.1 . " 4. Acceptable G-PID list: a list of G-PIDs corresponding to the "client" digital streams that is compatible with this device." Why is this a problem when "client devices" (e.g. routers in Fig.7) advertise their G-PID (see RFC 4202). --> This is a reminder that GPID can be important for optical networks too. Optical networks are not necessarily as "transparent" as people are led to believe. o) Section 6.2.3 . " 1. These are the per port wavelength restrictions of an optical device such as a ROADM and are independent of any optical constraints imposed by a fiber link." The term "per port" seems to contradict the description and the actual attribute association. See also above comment concerning this "restriction". --> This statement is clarifying the difference between the source of the wavelength restriction (i.e. the ROADM versus the fiber). Can remove if desired. . "4. Not necessarily needed in the case of distributed wavelength assignment via signaling." The fundamental question isn't answered the combined RWA and separate RWA are by definition centralized and global approaches (the computing node has complete topology information and computes all paths even those for which it isn't the source) -> why delocalizing them on each node makes the assumption that the information exchange should de-facto rely on "link-state routing" (the question isn't whether RWA needs this information or not, it does); on this point, there is an interesting discussion initiated on bullet 4, Section 4.2 but it seems that alternatives weren't considered at the end. Not the intention here to remove or to preclude that option but ask to document/motivate the proposed selection in the context of this framework. --> Alternatives along these lines were discussed at the PCE group but not adopted as a work item. o) Other remarks . There is no discussion about contention resolution in case of concurrency among requests, MBB applicability, and use of LMP (is the latter not foreseen or not usable in the WSON context ?). --> Current mechanisms suffice for WSON, i.e., WSON isn't so different from SONET/SDH in this regard. . Understanding that minimizing the number of re-trials/crankback is a reasonable goal; however, the question of extensions to crankback RFC and related that will be needed in case of multiple concurrent requests isn't discussed at all e.g. should the retry go back to the source or to intermediate nodes ? in which conditions ? etc. --> Good question for PCE. Not specific to WSON. Thanks, -dimitri. -----Original Message----- From: Rtg Area Wiki [mailto:trac@tools.ietf.org] Sent: Wednesday, January 19, 2011 12:12 AM To: Papadimitriou, Dimitri (Dimitri); dbrungard@att.com Cc: danli@huawei.com; adrian.farrel@huawei.com; stbryant@cisco.com Subject: Re: [Rtg Area Wiki] #49 (waiting): Review of draft-ietf-ccamp-rwa-wson-framework #49: Review of draft-ietf-ccamp-rwa-wson-framework Changes (by dbrungard@...): * cc: adrian.farrel@..., stbryant@... (added) * owner: dbrungard@... => dimitri.papadimitriou@... * status: open => waiting Old description: New description: By 2/1. -- -- ------------------------------+------------------------------- -------------- Reporter: dbrungard@... | Owner: dimitri.papadimitriou@... Type: review | Status: waiting Priority: major | Version: Keywords: wson gmpls | Draft: draft-ietf-ccamp-rwa-wson-framework ------------------------------+------------------------------- -------------- Ticket URL: Rtg Area Wiki = -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 ------=_NextPart_000_0E43_01CBC465.7F1D9FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi please go ahead with a new = revision.

 

Only point to note is = "optical subnetwork". I advise against that as the term = subnetwork has a very specific IETF meaning, and overloading it with = ITU-T meaning is at best going to cause people to whinge. I think that = whenever you say "network" you actually mean "WSON". = You could throw that statement in up front, or you could search and = replace network/WSON.

 

Thanks for the = work,

Adrian

 

 

From: = Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: 03 = February 2011 22:18
To: adrian@olddog.co.uk
Cc: = draft-ietf-ccamp-rwa-wson-framework@tools.ietf.org; = ccamp-chairs@tools.ietf.org; 'CCAMP'; = Dimitri.Papadimitriou@alcatel-lucent.com
Subject: Re: Routing = Directorate:Review of = draft-ietf-ccamp-rwa-wson-framework

 

Thanks for the = review. Please see comments below and confirm agreement on proposed = actions before we make changes to the document.

Greg & = Young

On 2/1/2011 1:09 PM, Adrian Farrel wrote: = 

Hi authors of =
draft-ietf-ccamp-rwa-wson-framework,
 
Here is the Routing Directorate review of your draft. =
Dimitri sent it into the
ADs during the IETF last =
call period, and I would appreciate you handling =
the
comments as if they were last call =
comments.
 
Most of his =
points look pretty sound to me, so I think you will need to =
do
another =
revision.
 
Many =
thanks,
Adrian
 
-----Original =
Message-----
From: Papadimitriou, Dimitri (Dimitri) =
[mailto:dimitri.papadimitrio=
u@alcatel-
lucent.com]
Sent=
: 31 January 2011 23:42
To: dbrungard@att.com
<= pre>Cc: danli@huawei.com; adrian.farrel@huawei.com; = stbryant@cisco.com
Subject: RE: [Rtg Area Wiki] #49 (waiting): Review =
of
draft-ietf-ccamp-rwa-wson-
framework<=
/pre>
 
Hi,
 =
;
Here below my review of this =
document:
 
o) Section 1. =
Introduction
 
. State =
the actual issue(s) when applying current GMPLS (RFC X,Y,Z) =
to
wavelength switched networks to initiate such =
"framework" otherwise one could
think of =
a BCP

-->  The = fundamental new issues raised are: (a) asymmetry of switching nodes, (b) = RWA control plane architectural alternatives (particularly including = PCE),  (c) optical signal compatibility (for path selection). =

The detailed comparison to specific GMPLS RFCs are given in = section 6, however we can add a paragraph or two of summary text to the = introduction. 

 
. RFC 3945 mention support of wavelength/lambda switching is that =
different
from WSON ? or is the second a special =
case of the former (note this is =
how
the
terminology section =
reads).

--> All = "GMPLS" applications fall under the general description = provided by RFC3945. The wavelength/lambda switching of RFC3945 is very = general, in this document we rigorize the notions with the definition of = optical signals in section 3.3 (based on ITU-T definitions). This helps = clarify the use of amplifiers and regenerators and their implications = for the control plane.
--> can add text to introduction clarifying = relation to RFC3945. 

 
. "In order to provision an optical connection (an optical =
path) through
a WSON certain path continuity and =
resource availability constraints
must be met to =
determine viable and optimal paths through the =
network."
 
I will =
come back to this latter but the term "network" is to be =
qualified =
in
context
of this document. In =
particular, afaik aren't there different =
specifications
of =
IaDI
and IrDI =
interfaces.

--> suggest = changing "network" to "optical subnetwork". = 

 
. "Note that this document focuses on the generic properties =
of links,
switches and path selection constraints =
that occur in =
WSONs."
 
  in which sense the term =
"generic" is used in this statement =
(usually
considered
as =
application to multiple switching =
technologies)
 
The main =
comment concerning this introduction is that the "motivation" =
(what's
the problem) and "positioning" =
(how it positions ?) shall be clarified.

-->  "Generic" in the sense of those = properties of optical networks found across different contexts such as = access, metro, and long haul.
--> Suggest changing order of last = two sentences of last paragraph of introduction. = 

 
o) Section 3.1
 
. =
" The number of channels is
   significantly smaller =
than the 32 bit GMPLS label space defined for
   GMPLS, see =
[RFC3471].  A label =
representation for these ITU-T grids
   is given in [Otani] and =
provides a common label format to be used in
   signaling optical paths. =
"
 
This falls into =
a Section describing (C)WDM links. It would be appropriate =
to
move
such material into a =
sub-section describing the corresponding =
GMPLS/link
capabilities. The same remark applies to =
Section 3.2 and 3.3: it would be
appropriate to =
have a sub-section dedicated to the implication on the =
control
plane (first) and then to GMPLS =
protocols.

--> This document = has been through numerous revisions and last calls and its present = structure represents working group consensus. Would not recommend the = proposed restructuring at this point in time.

 
o) Section 3.2
 
. =
Transmitter failure isn't specific to "WSON" but implications =
are the same
or =
not
? If a DXC =
transmitter fails clearly the node shall select another =
outgoing
interface.

-->  Your statement is true for a digital cross connect. = However for a transparent network the problem would be with the source = node and not the optical network. 

 
. "Hence, additional mechanisms
   may be necessary to =
detect and differentiate this failure from =
the
   =
others, e.g., one doesn't not want to initiate mesh restoration =
if
   =
the source transmitter has failed, since the optical transmitter =
will
   =
still be failed on the alternate optical =
path."
 
This =
example is rather confusing, if a source transmitter fails of =
course
selecting =
a
path along that =
transmitter won't work.

--> See above comments. This text was suggested by another = working group chair/AD. We could remove this entire discussion, but that = may cause us trouble with a different chair/AD... = 

 
o) Section =
3.3
 
.  "Note that a number of =
non-standard or proprietary modulation =
formats
   and FEC codes are =
commonly used in WSONs. For some digital bit
   streams the presence of =
Forwarding Equivalence Class (FEC) can =
be

=3D=3D> error in = text should be "Forward Error Correction" = 

   detected, e.g., in =
[G.707] this is indicated in the signal itself =
via
   =
the FEC Status Indication (FSI) byte, while in [G.709] this can =
be
   =
inferred from whether the FEC field of the Optical Channel =
Transport
   Unit-k (OTUk) is all =
zeros or =
not."
 
Please =
indicate the impact at the control plane level, and GMPLS =
protocol
level.

--> Will fix error in text. 

 
o) Section 3.4
 
. =
"Only a subset of these and their non-impairment related =
properties
   are considered in the =
following =
sections."
 
How =
that subset has been selected ? Why not the full set ? Does it mean =
that
the
GMPLS capabilities =
will only apply to this subset ?

--> Will change text to read "only the subset of these = relevant to the control plane". 

 
. "As the degree of the
   ROADM increases beyond =
two it can have properties of both a switch
   (OXC) and a multiplexer =
and hence it is necessary to know the
   switched connectivity =
offered by such a network element to
   effectively utilize it. =
"
 
These =
constraints are equivalent to link administrative coloring =
with
combinatorial
combination =
that can be encoded in their mask. I am not stating this would =
be
more effective than the proposed bit maps but =
how these constraint =
differs
from
a MT routing when =
constraints are induced by node structure or =
topological
considerations.

--> this statement is concerned with the connectivity = capabilities of a switch which was modeled via the connectivity matrix = mechanism. 

 
o) Section 3.4.2. and =
3.4.3
 
. Are combiners =
and splitters also controlled by means of GMPLS. Splitter =
have
"fixed connectivity matrix" what is =
then the role of GMPLS / control plane ?

--> Fixed connectivity devices tend to be used in conjunction = with switched devices. Hence their presence is crucial in determining = paths. 

 
. Same question applies for =
combiners.

--> See above. = 

 
. The side question how hybrid environment would operate (e.g. =
GMPLS/OXC
with non-GMPLS splitters or =
combiners)

-->  Would = need to use the network management system. Out of our scope. = 

 
o) Section 3.4.4 on Fixed Optical Add/Drop Multiplexers appears =
as =
a
particular
case of ROADMs not =
sure whether the need a dedicated =
sub-section

-->  Suggest = leaving the section. Since these are common in optical networks. = 

 
o) Section 3.5
 
. =
A definition of "transparency" would be more than welcome to =
understand the
remaining part of this =
sub-section
 
. The =
statement "they can be more or less "transparent" to an =
"optical signal"
depending on their =
functionality and/or implementation." should be =
clarified

-->  The = definitions of the different levels of regenerators (from optical = amplifiers to 3R) serves to illustrate the somewhat vague concept of = "transparency".  There is no formal definition of = "transparency" and previous attempts to make one ran into = difficulties (not defined by ITU-T, not clear what this would mean when = nonlinearities are introduced). 

 
o) Section =
3.5.1
 
. States =
"What this table also shows by its omission is that no switching =
or
multiplexing occurs at this layer." the =
"this" refers to ?

--> Will change text to read "What table 2 also = shows..." 

 
o) Section =
3.5.2
 
. This section =
speaks more about regenerators than OEO (whereas this =
Section
entitled OEO Switches). The relationship =
between OEO and regeneration isn't
explicit from =
the text and should be outlined to =
ease
understanding/readability
of this part of the =
document.

-->  Suggest = rearranging order of sentences 2 and 3 of this paragraph and rewording a = bit to make functionality of OEO switches and their relation to = regeneration clearer. 

 
o) Section 3.6
 
. =
" In WSONs where wavelength converters are sparse an optical path =
may
   =
appear to loop or "backtrack" upon itself in order to =
reach a
   wavelength converter =
prior to continuing on to its =
destination."
 
There=
 is a point to clarify here. A physical constraint would generate a =
loop
that
can only be detected =
by means of RRO (but it is receiver which breaks the =
loop
not the =
sender).
 

--> Yes.  No change to text seems indicated. = 

o) Section =
3.6.1
 
. It seems from =
its description that a conversion pool is a particular case =
of
use of
adjustment =
descriptor defined in RFC 6001 (that is a general mean to =
associate
resource pools to =
SC).

--> This is = similar in concept, except we are not treating this as a MLN/MRN problem = but as a single layer since there is essentially only one level of = switching capability. 

 
o) Section 4
 
. =
>From the description can authors confirm/infirm whether this =
framework
applies to a single "TE domain" =
thus in practice a single routing area ? =
or
not ?


--> This document does not address multiple AS issues. = 

 
. "It is to be noted that the choice of specific RWA =
algorithm is out of
   the scope for this =
document"
 
  The more fundamental question =
is whether all RWA algorithms can be covered
or not =
by a single set of non-contending extensions/mechanisms or not; =
this
point is to be clarified as whether the =
proposed framework is "generic" =
or
further
specialisation is =
still to be expected ?

-->  There are RWA techniques (not purely algorithms) = that utilize distributed mechanisms that do not fit with the GMPLS/PCE = signaling and routing paradigm.  However, the combined RWA = architecture of 4.1.1 can support any algorithm by definition.  No = further specialization is expected. 

 
. Worth mentioning that the RWA problem is NP Complete. Thus =
"optimality"
should more carefully =
qualified here. More importantly (in the context of =
this
document) which level of sub-optimality is =
considered as acceptable in =
terms
of
first =
rejection/retrial and second rejection/retrial this would provide =
nice
bounds
on what the control =
suite should deliver (taking into account what it =
is
capable =
to
deliver).<=
/pre>

--> Previous = editions of this document pointed out the complexity of the RWA problem = and to surveys such as

[1]

H. Zang, J. Jue, and = B. Mukherjeee, “A review of routing and wavelength assignment = approaches for wavelength-routed optical WDM networks,” Optical = Networks Magazine, 2000.  

that show the types algorithms and situations that can arise. = Such information was removed at the request of WG chairs and/or ADs. = 

 
o) Section =
4.1.3
 
. It is required =
to distinguish signaling of unidirectional vs =
bidirectional
path =
and
emphasize that the =
issue it is the upstream assignment in bi-dir LSP which =
is
issuing blocking not the downstream label one =
(indeed on the downstream
direction label =
assignment can't be blocking in terms of continuity =
otherwise
there no wavelength left for such =
assignment). The true problem is =
the
upstream
label assignment =
and the error issued (cf. Acceptable Label Set) never =
sorted
out
actually -- just for =
the record: =
<http://tools.ietf.org/html/draft-oki-ccamp-
=
=
upstream-labelset-00> ;-)

--> acknowledged. 

 
o) Section 4.2
 
. =
"Utilize incremental updates if feasible." of which =
information assuming one
refers to routing =
information here ? are incremental updates intended =
to
decrease the number of state updates or the rate =
of updates ?

--> = "incremental" updates of link information, particularly = available bandwidth. Can remove this statement if desired. = 

 
o) Section 5.2
 
. =
"The calculation of optical impairment feasible routes is outside =
the
   =
scope of this document. In general impairment feasible routes =
serve
   =
as an input to RWA =
algorithm.
 
  It is advisable to qualify what =
is an "impairment" vs "optical =
impairment"
against
a =
constraint induced by regeneration, conversion used to elevate =
these
impairments.
=3D=3D> Error in text. All impairments we are talking about =
are optical. Will insert the word "optical". =

 
o) Section =
6.2.1
 
. "  4. Acceptable G-PID list: a =
list of G-PIDs corresponding to the
     =
"client" digital streams that is compatible with this =
device."
 
Why is =
this a problem when "client devices" (e.g. routers in Fig.7) =
advertise
their
G-PID (see RFC =
4202).
-->  This is =
a reminder that GPID can be important for optical networks too.  =
Optical networks are not necessarily as "transparent" as =
people are led to believe. 
 
o) Section =
6.2.3
 
. " 1. These =
are the per port wavelength restrictions of an =
optical
      device =
such as a ROADM and are independent of any =
optical
      =
constraints imposed by a fiber =
link."
 
The term =
"per port" seems to contradict the description and the =
actual
attribute
association. =
See also above comment concerning this =
"restriction".
--> This statement is clarifying the difference between the =
source of the wavelength restriction (i.e. the ROADM versus the =
fiber).  Can remove if desired. 
 
. "4. Not necessarily needed in the case of distributed =
wavelength
      =
assignment via =
signaling."
 
The =
fundamental question isn't answered the combined RWA and separate =
RWA
are by definition  centralized and global =
approaches (the computing node has
complete =
topology information and computes all paths even those for which =
it
isn't the source) -> why delocalizing them on =
each node makes the assumption
that the information =
exchange should de-facto rely on "link-state =
routing"
(the
question =
isn't whether RWA needs this information or not, it does); on =
this
point,
there is an =
interesting discussion initiated on bullet 4, Section 4.2 but =
it
seems
that alternatives =
weren't considered at the end. Not the intention here =
to
remove or to preclude that option but ask to =
document/motivate the proposed
selection in the =
context of this framework.
--> Alternatives along these lines were discussed at the PCE =
group but not adopted as a work item. 
 
o) Other =
remarks
 
. There is no =
discussion about contention resolution in case of =
concurrency
among
requests, MBB =
applicability, and use of LMP (is the latter not foreseen or =
not
usable in the WSON context =
?).
--> Current =
mechanisms suffice for WSON, i.e., WSON isn't so different from =
SONET/SDH in this regard.

 
. Understanding that minimizing the number of re-trials/crankback =
is =
a
reasonable
goal; however, the =
question of extensions to crankback RFC and related =
that
will
be needed in case of =
multiple concurrent requests isn't discussed at all =
e.g.
should the retry go back to the source or to =
intermediate nodes ? in which
conditions ? =
etc.
--> Good question =
for PCE. Not specific to WSON. 
 
Thanks,
-dimitri.
&=
nbsp;
 
 
=

-----Original =
Message-----
From: Rtg Area Wiki [mailto:trac@tools.ietf.org]<=
/o:p>
Sent: Wednesday, January 19, 2011 12:12 =
AM
To: Papadimitriou, Dimitri (Dimitri); dbrungard@att.com
<=
pre>Cc: danli@huawei.com; adrian.farrel@huawei.com; =
stbryant@cisco.com
Subject: Re: [Rtg Area Wiki] #49 (waiting): Review =
of
draft-ietf-ccamp-rwa-wson-framework
 
#49: Review of =
draft-ietf-ccamp-rwa-wson-framework
 
Changes (by =
dbrungard@...):
 
 * cc: =
adrian.farrel@..., stbryant@... (added)
  * owner:  dbrungard@... =3D> =
dimitri.papadimitriou@...
  * status:  open =3D> =
waiting
 
 
Old =
description:
 
 =

 
New =
description:
 
 By =
2/1.
 
--
=

 
--
----------------=
--------------+-------------------------------
-----=
---------
Reporter:  dbrungard@...        =
|     =
Owner:
dimitri.papadimitriou@...
    =
Type:  review       &nbs=
p;     |    Status:  =
waiting
 
Priority:=
  major       &nbs=
p;      |   =
Version:
 
Keywords=
:  wson gmpls       &nbs=
p; |     =
Draft:
draft-ietf-ccamp-rwa-wson-framework
------------------------------+-----------------------=
--------
--------------
&n=
bsp;
Ticket URL:
<=
;http://trac.tools.ietf.org/area/rtg/trac/ticket/49#comment:2>
Rtg Area Wiki <http://tools.ietf.org/area/r=
tg/>
 
=3D
 
&=
nbsp;



-- =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
 
<= /html> ------=_NextPart_000_0E43_01CBC465.7F1D9FE0-- From gregb@grotto-networking.com Mon Feb 7 08:41:36 2011 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 5846D3A6E14 for ; Mon, 7 Feb 2011 08:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMC+BKlD8e-C for ; Mon, 7 Feb 2011 08:41:35 -0800 (PST) Received: from mail30c40.carrierzone.com (mail30c40.carrierzone.com [209.235.156.170]) by core3.amsl.com (Postfix) with ESMTP id 190DF3A6E44 for ; Mon, 7 Feb 2011 08:41:34 -0800 (PST) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.125] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail30c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id p17GfWFN018735; Mon, 7 Feb 2011 16:41:34 GMT Message-ID: <4D5020B8.8060109@grotto-networking.com> Date: Mon, 07 Feb 2011 08:41:28 -0800 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <081601cbc254$49677730$dc366590$@olddog.co.uk> <4D4B297F.4070701@grotto-networking.com> <0e4201cbc465$7f0cd700$7d268500$@olddog.co.uk> In-Reply-To: <0e4201cbc465$7f0cd700$7d268500$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------090702090604060804050001" X-CSC: 0 X-CHA: v=1.1 cv=wD5U+mCNT4tD6izdU8x0HmLJRkSMny8B6TekPf/9FM0= c=1 sm=1 a=3fpuP-AUP0sA:10 a=OkPnmgdRXU7//wtL+yd+jg==:17 a=VZAVAGJQAAAA:8 a=AEDFM0qtAAAA:8 a=48vgC7mUAAAA:8 a=gxZvrgisAAAA:8 a=RtVH1ZNPDq86tuzzVcgA:9 a=HF8ZmRteecXVdx1S8nwg6clk0qEA:4 a=wPNLvfGTeEIA:10 a=EgY3od2ZU2QA:10 a=h-I_03WOSDMA:10 a=m1nndEFD3LoA:10 a=jqlaW5bC1iAA:10 a=3FZX-ydVlcEA:10 a=DIHJPx_v-1wBorV5fBkA:9 a=Jb8h_z0C__RhH0Z77SUA:7 a=sDyKP557iGnNIfJrn608v1U1HVwA:4 a=OkPnmgdRXU7//wtL+yd+jg==:117 Cc: draft-ietf-ccamp-rwa-wson-framework@tools.ietf.org, ccamp-chairs@tools.ietf.org, 'CCAMP' , Dimitri.Papadimitriou@alcatel-lucent.com Subject: Re: [CCAMP] Routing Directorate:Review of draft-ietf-ccamp-rwa-wson-framework 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, 07 Feb 2011 16:41:36 -0000 This is a multi-part message in MIME format. --------------090702090604060804050001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi CCAMPers and WSON interested parties. We have just uploaded the newest version of the WSON framework with the previously mentioned changes. Note we used "WSON" rather than the ITU-T term "optical subnetwork" per Adrian's recommendation. Cheers Greg & Young On 2/4/2011 4:17 AM, Adrian Farrel wrote: > > Hi please go ahead with a new revision. > > Only point to note is "optical subnetwork". I advise against that as > the term subnetwork has a very specific IETF meaning, and overloading > it with ITU-T meaning is at best going to cause people to whinge. I > think that whenever you say "network" you actually mean "WSON". You > could throw that statement in up front, or you could search and > replace network/WSON. > > Thanks for the work, > > Adrian > > *From:*Greg Bernstein [mailto:gregb@grotto-networking.com] > *Sent:* 03 February 2011 22:18 > *To:* adrian@olddog.co.uk > *Cc:* draft-ietf-ccamp-rwa-wson-framework@tools.ietf.org; > ccamp-chairs@tools.ietf.org; 'CCAMP'; > Dimitri.Papadimitriou@alcatel-lucent.com > *Subject:* Re: Routing Directorate:Review of > draft-ietf-ccamp-rwa-wson-framework > > Thanks for the review. Please see comments below and confirm agreement > on proposed actions before we make changes to the document. > > Greg & Young > --snip-- -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------090702090604060804050001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi CCAMPers and WSON interested parties. We have just uploaded the newest version of the WSON framework with the previously mentioned changes.  Note we used "WSON" rather than the ITU-T term "optical subnetwork" per Adrian's recommendation.
Cheers
Greg & Young
On 2/4/2011 4:17 AM, Adrian Farrel wrote:

Hi please go ahead with a new revision.

 

Only point to note is "optical subnetwork". I advise against that as the term subnetwork has a very specific IETF meaning, and overloading it with ITU-T meaning is at best going to cause people to whinge. I think that whenever you say "network" you actually mean "WSON". You could throw that statement in up front, or you could search and replace network/WSON.

 

Thanks for the work,

Adrian

 

 

From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: 03 February 2011 22:18
To: adrian@olddog.co.uk
Cc: draft-ietf-ccamp-rwa-wson-framework@tools.ietf.org; ccamp-chairs@tools.ietf.org; 'CCAMP'; Dimitri.Papadimitriou@alcatel-lucent.com
Subject: Re: Routing Directorate:Review of draft-ietf-ccamp-rwa-wson-framework

 

Thanks for the review. Please see comments below and confirm agreement on proposed actions before we make changes to the document.

Greg & Young

--snip-- 
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------090702090604060804050001-- From Internet-Drafts@ietf.org Mon Feb 7 08:45:02 2011 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 606453A6E22; Mon, 7 Feb 2011 08:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwTsECcrPm1K; Mon, 7 Feb 2011 08:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697253A6E1B; Mon, 7 Feb 2011 08:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110207164501.31475.59800.idtracker@localhost> Date: Mon, 07 Feb 2011 08:45:01 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-wson-framework-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: Mon, 07 Feb 2011 16: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 : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Author(s) : G. Bernstein Filename : draft-ietf-ccamp-rwa-wson-framework-11.txt Pages : 53 Date : 2011-02-07 This document 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, it examines Routing and Wavelength Assignment (RWA) of optical paths. This document 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-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-rwa-wson-framework-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-07083510.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Tue Feb 8 08:45:02 2011 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 E21AE3A67AD; Tue, 8 Feb 2011 08:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wH4m24s3UCBE; Tue, 8 Feb 2011 08:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C633A6768; Tue, 8 Feb 2011 08:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110208164502.4827.71370.idtracker@localhost> Date: Tue, 08 Feb 2011 08:45:02 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-wson-framework-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, 08 Feb 2011 16:45: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 : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) Author(s) : G. Bernstein Filename : draft-ietf-ccamp-rwa-wson-framework-12.txt Pages : 53 Date : 2011-02-08 This document 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, it examines Routing and Wavelength Assignment (RWA) of optical paths. This document 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-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-rwa-wson-framework-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-08083939.I-D@ietf.org> --NextPart-- From gregb@grotto-networking.com Tue Feb 8 08:45:28 2011 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 048283A67E9 for ; Tue, 8 Feb 2011 08:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O31z0ifMxhiD for ; Tue, 8 Feb 2011 08:45:27 -0800 (PST) Received: from mail30c40.carrierzone.com (mail30c40.carrierzone.com [209.235.156.170]) by core3.amsl.com (Postfix) with ESMTP id 1D50D3A67E2 for ; Tue, 8 Feb 2011 08:45:26 -0800 (PST) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.125] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail30c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id p18GjVZA009245 for ; Tue, 8 Feb 2011 16:45:33 GMT Message-ID: <4D517327.60406@grotto-networking.com> Date: Tue, 08 Feb 2011 08:45:27 -0800 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CSC: 0 X-CHA: v=1.1 cv=wD5U+mCNT4tD6izdU8x0HmLJRkSMny8B6TekPf/9FM0= c=1 sm=1 a=rzGasJv4p34A:10 a=8nJEP1OIZ-IA:10 a=OkPnmgdRXU7//wtL+yd+jg==:17 a=PukkIbeFAE7aCiEn3NYA:9 a=rxsgtm4sO2ktlPPCRYklUpjM6ksA:4 a=wPNLvfGTeEIA:10 a=EgY3od2ZU2QA:10 a=h-I_03WOSDMA:10 a=OkPnmgdRXU7//wtL+yd+jg==:117 Subject: [CCAMP] WSON Framework update version 12 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 Feb 2011 16:45:28 -0000 Hi folks, this version includes all Gen-ART fixes. These are editorial in nature. Best Regards Greg & Young -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From takeda.tomonori@lab.ntt.co.jp Wed Feb 9 07:02:41 2011 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 70A483A69A8; Wed, 9 Feb 2011 07:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.89 X-Spam-Level: X-Spam-Status: No, score=-98.89 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, 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 oNDqTJqwJklB; Wed, 9 Feb 2011 07:02:40 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id 1425E3A6767; Wed, 9 Feb 2011 07:02:39 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.14.4/8.14.4) with ESMTP id p19F2m2H028639; Thu, 10 Feb 2011 00:02:48 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 70A486D3D; Thu, 10 Feb 2011 00:02:48 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2-mgr.m.ecl.ntt.co.jp [129.60.144.42]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 4AD2E6D39; Thu, 10 Feb 2011 00:02:48 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (webmail.ecl.ntt.co.jp [129.60.39.130]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id p19F2mPp015543; Thu, 10 Feb 2011 00:02:48 +0900 Message-Id: <201102091502.p19F2mPp015543@imail2.m.ecl.ntt.co.jp> To: ccamp@ietf.org, pce@ietf.org, mpls@ietf.org, mpls-tp@ietf.org From: Tomonori TAKEDA Date: Thu, 10 Feb 2011 00:02:48 +0900 X-Mailer: WebMail V3.7 PL3 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Cc: iPOP2011-tpc-sec@pilab.jp Subject: [CCAMP] iPOP2011 Call for Presentation X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 15:02:41 -0000 (Apologies if you received multiple copies of this message.) Dear CCAMP, PCE, MPLS and MPLS-TP subscribers, iPOP2011 Call for Presentation is now open as follows. The deadline for submitting presentation proposal is February 25th. Best Regards, Tomonori Takeda ------------------------------------------------------------------------ Call for Presentation 7th International Conference on IP + Optical Network (iPOP 2011) June 2-3, 2010 NEC Tamagawa Plant, Kanagawa, Japan http://www.pilab.jp/ipop2011/ The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. Important Dates: Submission deadline of one-page abstract: February 25, 2010 Notification of acceptance: April 4, 2010 Submission deadline of final presentation slides: April 22, 2010 The Technical Program Committee for iPOP 2010 is soliciting presentation proposals for this conference. Protocol design, experiment, theory, implementation, and operational experiences are solicited. The topics of the conference will include but not limited to the following: * GMPLS/ASON technologies * GMPLS Network management, OA&M * Multi-layer network (MLN) / Multi-region network (MRN) * Path Computation Element (PCE), Traffic engineering * Inter-area/Inter-AS network * L1VPN, Bandwidth on Demand, and Photonic Grid * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, Impairment management * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet transport technologies * Carrier Ethernet and MPLS-TP * Photonic Network for NxGN and NwGN * Application with high-bandwidth demand * Testbed, field trial If you wish to submit a topic for consideration, please send an Extended Abstracts of a 400 words and a maximum of 1 page, including figures and diagrams, speaker$B!G(Bs name, affiliation, and contact information to the Technical Program Committee at ipop2011-CFP@pilab.jp. Please see http://www.pilab.jp/ipop2011/ for more details. ---------------------------------------------------------------------- From Internet-Drafts@ietf.org Thu Feb 10 06:15:02 2011 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 735BD3A69AA; Thu, 10 Feb 2011 06:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPvlYbLQODqP; Thu, 10 Feb 2011 06:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F88F3A694F; Thu, 10 Feb 2011 06:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110210141501.4357.50359.idtracker@localhost> Date: Thu, 10 Feb 2011 06:15:01 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-mpls-tp-cp-framework-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 14: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 : MPLS-TP Control Plane Framework Author(s) : L. Andersson, et al. Filename : draft-ietf-ccamp-mpls-tp-cp-framework-06.txt Pages : 55 Date : 2011-02-10 The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS), and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for Pseudowires (PWs). Management plane functions are out of scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF consensus.] A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-cp-framework-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-mpls-tp-cp-framework-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-10060340.I-D@ietf.org> --NextPart-- From vijayc@hcl.com Thu Feb 10 07:48:16 2011 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 D321C3A69C8 for ; Thu, 10 Feb 2011 07:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.453 X-Spam-Level: ** X-Spam-Status: No, score=2.453 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWIsXq8s2-K9 for ; Thu, 10 Feb 2011 07:48:15 -0800 (PST) Received: from gws08.hcl.com (gws08.hcl.com [203.105.186.26]) by core3.amsl.com (Postfix) with ESMTP id 318DD3A69AA for ; Thu, 10 Feb 2011 07:48:15 -0800 (PST) Received: from chn-hclin-ht02.CORP.HCL.IN (10.249.64.36) by CHN-HCLIN-EDGE4.HCL.COM (10.249.64.141) with Microsoft SMTP Server id 8.2.254.0; Thu, 10 Feb 2011 21:18:19 +0530 Received: from CHN-HCLT-CASHT1.HCLT.CORP.HCL.IN (10.108.45.33) by chn-hclin-ht02.CORP.HCL.IN (10.249.64.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 10 Feb 2011 21:18:24 +0530 Received: from CHN-HCLT-EVS07.HCLT.CORP.HCL.IN ([fe80::3d0d:efa3:3da8:2ae9]) by CHN-HCLT-CASHT1.HCLT.CORP.HCL.IN ([::1]) with mapi; Thu, 10 Feb 2011 21:18:24 +0530 From: "Vijayanand C - ERS, HCL Tech" To: "tnadeau@cisco.com" , "adrian@olddog.co.uk" , "cheenu@bloomberg.net" , "tim.hall@dataconnection.com" , "tim.hall@dataconnection.com" Date: Thu, 10 Feb 2011 21:18:23 +0530 Thread-Topic: question on rfc4803 Thread-Index: AQHLyTnyOsyY/caOHkO9X0SahKinDQ== Message-ID: <66E3DDEEA70F0D469D1FFE238526B6ED3E42D5053B@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" , "Balaji Radhakrishnan - ERS, HCL Tech" Subject: [CCAMP] question on rfc4803 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 Feb 2011 15:48:17 -0000
Hello a= ll.
How are the two directions of the cross c= onnect of the bidirectional LSP correlated
 
As per section 5, the cro= ss connects will have the same XC index.
"
The GMPLS-LSR-STD-MIB module supports bidirectional LS= Ps as required
   for GMPLS.  A single value of mplsXCIndex is shared by al= l of the
   segments for the entire bidirectional LSP.  This facilita= tes a simple
   reference from [RFC3812] = and [RFC4802] and makes fate-sharing more
   obvious.
"
 
But as per the example in= section 6, the xcindex can be different but the mplsXCLSPId must be same
&= nbsp;
" In mplsXCTable:
   {
      mplsXCIndex     &nb= sp;          =3D 0x01,
      mplsXCInSegmentIndex    =    =3D 0x00000015,
      mplsXCOutSegmentIndex    = ;  =3D 0x00000012,
      mplsXCLspId     &nb= sp;          =3D 0x0102 -- uni= que ID
      mplsXCLabelStackIndex    = ;  =3D 0x00, -- only a single outgoing label
      mplsXCRowStatus     = ;       =3D createAndGo(4)
   }

   In mplsXCTable:
   {
      mplsXCIndex     &nb= sp;          =3D 0x02,
      mplsXCInSegmentIndex    =    =3D 0x00000016,
      mplsXCOutSegmentIndex    = ;  =3D 0x00000013,
      mplsXCLspId     &nb= sp;          =3D 0x0102 -- uni= que ID
      mplsXCLabelStackIndex    = ;  =3D 0x00, -- only a single outgoing label
      mplsXCRowStatus     = ;       =3D createAndGo(4)
   }
"
 
Please clarify.
 
Regards
Vijay

::DISCLAIMER::
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliate= s. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect t= he opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender immedia= tely. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------
 From lberger@labn.net Thu Feb 10 10:40:09 2011 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 458603A69D6 for ; Thu, 10 Feb 2011 10:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 7GJvVY5hQqzh for ; Thu, 10 Feb 2011 10:40:09 -0800 (PST) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id 1710B3A6987 for ; Thu, 10 Feb 2011 10:40:09 -0800 (PST) Received: (qmail 5403 invoked by uid 0); 10 Feb 2011 18:33:42 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy2.bluehost.com with SMTP; 10 Feb 2011 18:33:42 -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:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=NgKhyUWP4jG8OspW4zGvhcimu8oplkNUPgHOzpnjLOY5Kx9XuaX0ViCq/4cKZQIEzjejlZdqTEHdxJc8H6IeF8dM4EVBGRVWPOPe0iuUoWLIrEBL/We7glV4kkpMiWaE; 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 1PnbKo-0006op-Cd; Thu, 10 Feb 2011 11:33:42 -0700 Message-ID: <4D542F85.6050607@labn.net> Date: Thu, 10 Feb 2011 13:33:41 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: ccamp@ietf.org, "mpls-tp@ietf.org" , "pwe3@ietf.org" , IESG References: <20110210141501.4357.50359.idtracker@localhost> In-Reply-To: <20110210141501.4357.50359.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-mpls-tp-cp-framework-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 18:40:09 -0000 FYI - this update was made to address IESG comments. Changes include: 1) Update references 2) Minor editorial changes, including: - acronym expansion, - wordsmithing, - clarification of terms 3) Removal (and consequential reordering) of requirement 38 (was "Requirement removed.") 4) Added additional references 5) Added (PW) section 5.1.1. to parallel (LSP) section 4.2.1 6) Removed some out-of-scope text Lou On 2/10/2011 9:15 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > > Title : MPLS-TP Control Plane Framework > Author(s) : L. Andersson, et al. > Filename : draft-ietf-ccamp-mpls-tp-cp-framework-06.txt > Pages : 55 > Date : 2011-02-10 > > The MPLS Transport Profile (MPLS-TP) supports static provisioning > of transport paths via a Network Management System (NMS), and > dynamic provisioning of transport paths via a control plane. This > document provides the framework for MPLS-TP dynamic provisioning, > and covers control plane addressing, routing, path computation, > signaling, traffic engineering, and path recovery. MPLS-TP uses > GMPLS as the control plane for MPLS-TP Label Switched Paths > (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for > Pseudowires (PWs). Management plane functions are out of scope of > this document. > > This document is a product of a joint Internet Engineering Task Force > (IETF) / International Telecommunication Union Telecommunication > Standardization Sector (ITU-T) effort to include an MPLS Transport > Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge > (PWE3) architectures to support the capabilities and functionalities > of a packet transport network as defined by the ITU-T. > > This Informational Internet-Draft is aimed at achieving IETF > Consensus before publication as an RFC and will be subject to an IETF > Last Call. > > [RFC Editor, please remove this note before publication as an RFC and > insert the correct Streams Boilerplate to indicate that the published > RFC has IETF consensus.] > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-cp-framework-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From iesg-secretary@ietf.org Thu Feb 10 13:23:55 2011 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 C3ED43A67D8; Thu, 10 Feb 2011 13:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IodSslWu+vfq; Thu, 10 Feb 2011 13:23:54 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2003A6A25; Thu, 10 Feb 2011 13:23:54 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110210212354.7651.92188.idtracker@localhost> Date: Thu, 10 Feb 2011 13:23:54 -0800 Cc: ccamp mailing list , Internet Architecture Board , ccamp chair , RFC Editor Subject: [CCAMP] Document Action: 'MPLS-TP Control Plane Framework' to Informational RFC (draft-ietf-ccamp-mpls-tp-cp-framework-06.txt) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 21:23:55 -0000 The IESG has approved the following document: - 'MPLS-TP Control Plane Framework' (draft-ietf-ccamp-mpls-tp-cp-framework-06.txt) as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ccamp-mpls-tp-cp-framework/ Technical Summary The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS), and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP LSPs. MPLS-TP also uses the Pseudowire (PW) control plane for Pseudowires (PWs). Management plane functions are out of scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. Working Group Summary Nothing worth noting. Document Quality This document is an informational framework. It was reviewed by the CCAMP, MPLS, and PWE3 working groups in both of its working group last calls. It was also liaised to the ITU-T in two revisions, and the received review comments were addressed. Personnel Deborah Brungard (db3546@att.com) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. From acee.lindem@ericsson.com Mon Feb 14 11:11:16 2011 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 4ED373A6DA3 for ; Mon, 14 Feb 2011 11:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKFzFpk0bSu2 for ; Mon, 14 Feb 2011 11:11:12 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 335F33A6DA4 for ; Mon, 14 Feb 2011 11:11:10 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p1EJuYNE021876; Mon, 14 Feb 2011 13:56:36 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 14 Feb 2011 14:11:23 -0500 From: Acee Lindem To: "Shew, Stephen" Date: Mon, 14 Feb 2011 14:11:22 -0500 Thread-Topic: [CCAMP] New Version Notification for draft-malis-ccamp-rfc5787bis-01 Thread-Index: AcvMevfwa/2svTz9QzC+LkNg8czBtw== Message-ID: References: <20100922094423.0F58F3A6967@core3.amsl.com> <585B7F67-3035-44D6-9BD5-E3D60C64F3D5@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-12--571581370"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] New Version Notification for draft-malis-ccamp-rfc5787bis-01 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 Feb 2011 19:11:17 -0000 --Apple-Mail-12--571581370 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Stephen, I know this response is late but I want to close the loop on your = comments with the CCAMP WG before we issue another version. My = understanding from discussions with my co-authors is that you will work = with us on the terminology comments (1, 2, 3, and 5a).=20 As for comments 4 and 5b, I don't think we can change the TLV = advertisement requirements for all OSPF TE, RFC 3630, et al, since = these changes would not be backward compatible nor required for all OSPF = TE applications. I do, however, think we could relax the general = requirement to advertise the Link-ID TLV in the cases where the Local = and Remote TE Router ID sub-TLVs are advertised.=20 Thanks, Acee On Oct 26, 2010, at 2:08 PM, Shew, Stephen wrote: > I have read draft-malis-ccamp-rfc5787bis-01.txt and was involved in = the discussion of it at the recent ITU-T Q12/15 interim meeting. I have = the following comments on it: >=20 > The main comment I have on the draft is that it is requires more = clarity on address/name spaces that various identifiers are part of, = especially distinguishing between the IP network address space and other = address/namespaces. In transport networks, there are different name = spaces associated with services, resources (data plane), management = functions, and the communications between those functions. ASON = (G.8080) can be viewed as another transport management function and thus = has the following name spaces: >=20 > Services - UNI and ENNI Transport Resource identifiers (known in OIF = IAs as Transport Network Addresses) > Resources - Subnetwork Point Pool (SNPP) names > Functions - Component (RC, NCC, CC, LRM, TAP, DS) names and Protocol = Controller names > Communications - The Signalling Communications Network (SCN) has = identifiers that are used for the purpose of sending information between = ASON components. These have similar meaning as L3 IP reachable = addresses. >=20 > Reading the draft then with this view of name spaces we make the = following comments: > 1. General. The term "reachability" can be confusing as the semantics = differ with the name space to which it is applied. If applied to the = resource or data plane, it means that the resource is visible in some = topology. If applied in the SCN context, it means that information can = be sent to that address using an IP network. If applied to the = component name space, it usually means that the information can be sent = to that component via the SCN. >=20 > 2. Section 3. In an ASON context, "TE router ID" is in the resource = name space and identifies a node/matrix in the transport network. The = "OSPF router ID" is in a component name space and represents the routing = function. >=20 > 3. Section 4. The term "reachability" should be clarified in this = section to mean identifiers in the resource plane that are advertised by = the routing function. They are not reachable in the same sense as = functions are pinged in IP. What can be confusing is that these = addresses may use the IPv4 or IPv6 address format, but are in a = different name space from IP routable addresses. >=20 > 4. Section 6.1. I would like to suggest that consideration be given = to always advertising the Local and Remote TE Router ID sub-TLV. This = would provide a consistent advertising behaviour for the ASON case and = make it possible to increase the scope of an OSPF router from one to two = TE Router IDs without changing the advertising format. >=20 > 5. Section 6.2. The term "reachability" should be clarified as noted = above (point 3). Also, I suggest that consideration be given to always = advertising the Local TE Router ID sub-TLV for the same reason given = above (point 4). >=20 > Stephen Shew | Director, Standards > sshew@ciena.com | 3500 Carling Ave. | Ottawa CANADA K2H 8E9 > Direct +1.613.763.2462 >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Acee Lindem > Sent: 23 September, 2010 09:49 > To: ccamp@ietf.org > Subject: Re: [CCAMP] New Version Notification for = draft-malis-ccamp-rfc5787bis-01 >=20 > Most of the changes in the this revision are an attempt to make the = document easier to understand for people unfamiliar with ITU ASON = terminology. This is in response to comments from Julien Meuric and = others at the IETF 78 CCAMP meeting.=20 >=20 > - Section 2 now contains text better explaining the = hierarchical relationship between RAs. Much of this is taken from RFC = 4258.=20 > - Section 3 has been rewritten with the description of an OSPF = router advertising on behalf multiple ASON transport nodes simplified. = The subscripted variables (Ri, Pi, and Li) have been removed in favor of = this simplified terminology. > - Section 5 includes solely editorial changes. Some of the = longer sentences have been split and some ambiguous language has been = clarified.=20 > - Section 6 has been rewritten to reflect the simplified = terminology introduced in section 3. Additionally, we have clarified = when the rules for inclusion of the new section 6 Sub-TLVs. We also = removed the restriction on when these new Sub-TLVs may be specified.=20 > - Section 7 includes some changes to reflect the new section 3 = terminology, as well as, a couple editorial changes.=20 >=20 > Lyndon Ong will coordinate review of this revision with the ITU = Q.12/15 SG at their Shanghai meeting.=20 >=20 > Thanks, > Acee >=20 > On Sep 22, 2010, at 5:44 AM, IETF I-D Submission Tool wrote: >=20 >>=20 >> A new version of I-D, draft-malis-ccamp-rfc5787bis-01.txt has been = successfully submitted by Andrew Malis and posted to the IETF = repository. >>=20 >> Filename: draft-malis-ccamp-rfc5787bis >> Revision: 01 >> Title: Updates to ASON Routing for OSPFv2 Protocols = (RFC 5787bis) >> Creation_date: 2010-09-22 >> WG ID: Independent Submission >> Number_of_pages: 20 >>=20 >> Abstract: >> The ITU-T has defined an architecture and requirements for operating >> an Automatically Switched Optical Network (ASON). >>=20 >> The Generalized Multiprotocol Label Switching (GMPLS) protocol suite >> is designed to provide a control plane for a range of network >> technologies including optical networks such as time division >> multiplexing (TDM) networks including SONET/SDH and Optical Transport >> Networks (OTNs), and lambda switching optical networks. >>=20 >> The requirements for GMPLS routing to satisfy the requirements of >> ASON routing, and an evaluation of existing GMPLS routing protocols >> are provided in other documents. This document defines extensions to >> the OSPFv2 Link State Routing Protocol to meet the requirements for >> routing in an ASON. >>=20 >> Note that this work is scoped to the requirements and evaluation >> expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations >> current when those documents were written. Future extensions of >> revisions of this work may be necessary if the ITU-T Recommendations >> are revised or if new requirements are introduced into a revision of >> RFC 4258. >>=20 >>=20 >>=20 >> The IETF Secretariat. >>=20 >>=20 >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp --Apple-Mail-12--571581370 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIxNDE5MTEyMlowIwYJKoZI hvcNAQkEMRYEFDAA76ErvK7IyjaFceGRoNV6G7n/MFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgI0J4bxA+wcpBTVfPXdQOaVaH4wJmODgpuzz3u7ITgNE5QoGfbSOFka8+Y2LoOc6 1aOXLe0iseh48cfTagdmTeGZqFZ+EAbCQIDHdUysx5iAFn7H8rl2e6jOQHj/srOycV89DXAj1gun UM6sePU/x+DNe3soNGNGQgGAXX7R54QqAAAAAAAA --Apple-Mail-12--571581370-- From julien.meuric@orange-ftgroup.com Wed Feb 16 05:16:57 2011 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 E92573A6CC3; Wed, 16 Feb 2011 05:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.349 X-Spam-Level: X-Spam-Status: No, score=-101.349 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, 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 o1lZufdTfMsi; Wed, 16 Feb 2011 05:16:57 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id A52063A6C8B; Wed, 16 Feb 2011 05:16:56 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7B76BFC4010; Wed, 16 Feb 2011 14:17:28 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 71678FC400E; Wed, 16 Feb 2011 14:17:28 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Feb 2011 14:17:23 +0100 Received: from [10.193.71.71] ([10.193.71.71]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Feb 2011 14:17:22 +0100 Message-ID: <4D5BCE62.9060408@orange-ftgroup.com> Date: Wed, 16 Feb 2011 14:17:22 +0100 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: pce@ietf.org, ccamp@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Feb 2011 13:17:22.0602 (UTC) FILETIME=[D89EF8A0:01CBCDDB] Subject: [CCAMP] Fwd: iPOP2011 Call for Presentation X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 13:16:58 -0000 FYI --------------------------------------------------------------------- Call for Presentation 7th International Conference on IP + Optical Network (iPOP 2011) June 2-3, 2010 NEC Tamagawa Plant, Kanagawa, Japan http://www.pilab.jp/ipop2011/ The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. Important Dates: Submission deadline of one-page abstract: February 25, 2010 Notification of acceptance: April 4, 2010 Submission deadline of final presentation slides: April 22, 2010 The Technical Program Committee for iPOP 2010 is soliciting presentation proposals for this conference. Protocol design, experiment, theory, implementation, and operational experiences are solicited. The topics of the conference will include but not limited to the following: * GMPLS/ASON technologies * GMPLS Network management, OA&M * Multi-layer network (MLN) / Multi-region network (MRN) * Path Computation Element (PCE), Traffic engineering * Inter-area/Inter-AS network * L1VPN, Bandwidth on Demand, and Photonic Grid * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, Impairment management * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet transport technologies * Carrier Ethernet and MPLS-TP * Photonic Network for NxGN and NwGN * Application with high-bandwidth demand * Testbed, field trial If you wish to submit a topic for consideration, please send an Extended Abstracts of a 400 words and a maximum of 1 page, including figures and diagrams, speaker$B!G(Bs name, affiliation, and contact information to the Technical Program Committee at ipop2011-CFP@pilab.jp. Please see http://www.pilab.jp/ipop2011/ for more details. -------------------------------------------------------------------- From fu.xihua@zte.com.cn Fri Feb 18 01:44:19 2011 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 07C233A6EF9 for ; Fri, 18 Feb 2011 01:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AY6xWC7NtOCY for ; Fri, 18 Feb 2011 01:44:18 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 9F7433A6EE7 for ; Fri, 18 Feb 2011 01:44:17 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 20595473195744; Fri, 18 Feb 2011 17:38:58 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 50584.473195744; Fri, 18 Feb 2011 17:34:47 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1I9hHnB043770 for ; Fri, 18 Feb 2011 17:43:17 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn) MIME-Version: 1.0 To: ccamp@ietf.org X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Fri, 18 Feb 2011 17:43:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-18 17:43:18, Serialize complete at 2011-02-18 17:43:18 Content-Type: multipart/alternative; boundary="=_alternative 003567EF4825783B_=" X-MAIL: mse01.zte.com.cn p1I9hHnB043770 Subject: Re: [CCAMP] New Version Notification for draft-wang-ccamp-latency-te-metric-02 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 Feb 2011 09:44:19 -0000 This is a multipart message in MIME format. --=_alternative 003567EF4825783B_= Content-Type: text/plain; charset="US-ASCII" Hi CCAMP, Based on the discussion in Beijing meeting, we refined the document and added a section about the requirement identification. http://tools.ietf.org/html/draft-wang-ccamp-latency-te-metric-02 Wish for your comments. Xihua Fu --=_alternative 003567EF4825783B_= Content-Type: text/html; charset="US-ASCII"
Hi CCAMP,

Based on the discussion in Beijing meeting, we refined the document and added a section about the requirement identification.
http://tools.ietf.org/html/draft-wang-ccamp-latency-te-metric-02
Wish for your comments.

Xihua Fu --=_alternative 003567EF4825783B_=-- From zheng.zhi@zte.com.cn Sat Feb 19 00:10:59 2011 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 4AC6B3A6D67 for ; Sat, 19 Feb 2011 00:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soMgZ883z7AZ for ; Sat, 19 Feb 2011 00:10:58 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 88A153A6CF8 for ; Sat, 19 Feb 2011 00:10:57 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 20595473195744; Sat, 19 Feb 2011 16:06:32 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 50584.473195744; Sat, 19 Feb 2011 16:02:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p1J8BKTE021858 for ; Sat, 19 Feb 2011 16:11:21 +0800 (GMT-8) (envelope-from zheng.zhi@zte.com.cn) In-Reply-To: <20110219075016.9ED783A6E76@core3.amsl.com> To: ccamp@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zheng.zhi@zte.com.cn Date: Sat, 19 Feb 2011 16:08:28 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-19 16:11:22, Serialize complete at 2011-02-19 16:11:22 Content-Type: multipart/alternative; boundary="=_alternative 002D53D64825783C_=" X-MAIL: mse02.zte.com.cn p1J8BKTE021858 Subject: [CCAMP] Problem of hostname display of each RSVP Hop 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 Feb 2011 08:10:59 -0000 This is a multipart message in MIME format. --=_alternative 002D53D64825783C_= Content-Type: text/plain; charset="US-ASCII" Hi, all: Hostname display for OSPF and RSVP-TE can improve the operating experience. But when initiating an inter-area LSP tunnel with RSVP-TE, and tried to get the hostname of each RSVP Hop display on the CLI at the ingress node, it is impossible to obtain the hostname information of those nodes in areas other than the initiator's. The hostname flooding scope is controlled by the OSPF Opaque LSA, as described in [RFC5642]. That means the hostname information of a router other than an ASBR, cannot traverse OSPF routing areas. The draft makes some extensions, please review and comment... http://tools.ietf.org/html/draft-zheng-ccamp-rsvp-te-dynamic-hostname-00 Best Regards, Zhi > > A new version of I-D, draft-zheng-ccamp-rsvp-te-dynamic-hostname-00. > txt has been successfully submitted by Zhi Zheng and posted to the > IETF repository. > > Filename: draft-zheng-ccamp-rsvp-te-dynamic-hostname > Revision: 00 > Title: RSVP-TE extensions for dynamic hostname traversing OSPF > routing areas > Creation_date: 2011-02-19 > WG ID: Independent Submission > Number_of_pages: 6 > > Abstract: > RFC 5642 defines an OSPF Router Information TLV that allows OSPF > Routers to flood their hostname-to-Router-ID mapping information. > Sometimes, when the operators create an inter-area MPLS LSP tunnel > with Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE), > they need the hostname display on the CLI at the ingress node for > management and operational reasons. This document describes > extensions to RSVP-TE to support hostname-to-Router-ID mapping > information traversing areas in an inter-area MPLS LSP tunnel > situation. > > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 002D53D64825783C_= Content-Type: text/html; charset="US-ASCII"
Hi, all:

Hostname display for OSPF and RSVP-TE can improve the operating experience. But when initiating an inter-area LSP tunnel with RSVP-TE, and tried to get the hostname of each RSVP Hop display on the CLI at the ingress node, it is impossible to obtain the hostname information of those nodes in areas other than the initiator's.
The hostname flooding scope is controlled by the OSPF Opaque LSA, as described in [RFC5642]. That means the hostname information of a router other than an ASBR, cannot traverse OSPF routing areas.
The draft makes some extensions, please review and comment...
http://tools.ietf.org/html/draft-zheng-ccamp-rsvp-te-dynamic-hostname-00

Best Regards,
Zhi
 


>
> A new version of I-D, draft-zheng-ccamp-rsvp-te-dynamic-hostname-00.
> txt has been successfully submitted by Zhi Zheng and posted to the
> IETF repository.
>
> Filename:    draft-zheng-ccamp-rsvp-te-dynamic-hostname
> Revision:    00
> Title:       RSVP-TE extensions for dynamic hostname traversing OSPF
> routing areas
> Creation_date:    2011-02-19
> WG ID:       Independent Submission
> Number_of_pages: 6
>
> Abstract:
> RFC 5642 defines an OSPF Router Information TLV that allows OSPF
> Routers to flood their hostname-to-Router-ID mapping information.
> Sometimes, when the operators create an inter-area MPLS LSP tunnel
> with Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE),
> they need the hostname display on the CLI at the ingress node for
> management and operational reasons.  This document describes
> extensions to RSVP-TE to support hostname-to-Router-ID mapping
> information traversing areas in an inter-area MPLS LSP tunnel
> situation.
>                                                                              
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 002D53D64825783C_=-- From takeda.tomonori@lab.ntt.co.jp Sun Feb 20 22:53:04 2011 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 B1F7F3A6F96; Sun, 20 Feb 2011 22:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.89 X-Spam-Level: X-Spam-Status: No, score=-98.89 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, 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 jUz2ls4kJ2uo; Sun, 20 Feb 2011 22:53:02 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id ADCAA3A6F93; Sun, 20 Feb 2011 22:53:02 -0800 (PST) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.14.4/8.14.4) with ESMTP id p1L6rgkq019415; Mon, 21 Feb 2011 15:53:42 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 289E665F1; Mon, 21 Feb 2011 15:53:42 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2.m.ecl.ntt.co.jp [129.60.5.247]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 1003A65EB; Mon, 21 Feb 2011 15:53:42 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.55]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id p1L6reHU009271; Mon, 21 Feb 2011 15:53:42 +0900 Message-ID: <4D620BDD.7000504@lab.ntt.co.jp> Date: Mon, 21 Feb 2011 15:53:17 +0900 From: Tomonori TAKEDA User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ccamp@ietf.org, pce@ietf.org, mpls@ietf.org, mpls-tp@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: iPOP2011-tpc-sec@pilab.jp Subject: [CCAMP] iPOP2011 Call for Presentation (corrected version) 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 Feb 2011 06:53:04 -0000 (Apologies if you received multiple copies of this message.) Dear CCAMP, PCE, MPLS and MPLS-TP subscribers, The email sent on Feb. 10th titled "iPOP2011 Call for Presentation" states wrong dates. It should be year "2011", not "2010". Please find the corrected CFP as follows. Sorry for your inconvenience. Tomonori Takeda ------------------------------------------------------------------- Call for Presentation 7th International Conference on IP + Optical Network (iPOP 2011) June 2-3, 2011 NEC Tamagawa Plant, Kanagawa, Japan http://www.pilab.jp/ipop2011/ The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. Important Dates: Submission deadline of one-page abstract: February 25, 2011 Notification of acceptance: April 4, 2011 Submission deadline of final presentation slides: April 22, 2011 The Technical Program Committee for iPOP 2011 is soliciting presentation proposals for this conference. Protocol design, experiment, theory, implementation, and operational experiences are solicited. The topics of the conference will include but not limited to the following: * GMPLS/ASON technologies * GMPLS Network management, OA&M * Multi-layer network (MLN) / Multi-region network (MRN) * Path Computation Element (PCE), Traffic engineering * Inter-area/Inter-AS network * L1VPN, Bandwidth on Demand, and Photonic Grid * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, Impairment management * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet transport technologies * Carrier Ethernet and MPLS-TP * Photonic Network for NxGN and NwGN * Application with high-bandwidth demand * Testbed, field trial If you wish to submit a topic for consideration, please send an Extended Abstracts of a 400 words and a maximum of 1 page, including figures and diagrams, speaker$B!G(Bs name, affiliation, and contact information to the Technical Program Committee at ipop2011-CFP@pilab.jp. Please see http://www.pilab.jp/ipop2011/ for more details. ----------------------------------------------------------------------- From db3546@att.com Mon Feb 21 09:09:21 2011 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 5817C3A6FE3 for ; Mon, 21 Feb 2011 09:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44MhPlTxyUE6 for ; Mon, 21 Feb 2011 09:09:20 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 773273A6DDB for ; Mon, 21 Feb 2011 09:09:20 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-7.tower-146.messagelabs.com!1298308201!28793165!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 32057 invoked from network); 21 Feb 2011 17:10:01 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Feb 2011 17:10:01 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p1LH96PG009076 for ; Mon, 21 Feb 2011 12:09:06 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p1LH91bH008994 for ; Mon, 21 Feb 2011 12:09:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Feb 2011 12:09:55 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG document poll for draft-zhang-ccamp-general-constraints-ospf-ext Thread-Index: AcvR6ilTO2ov9I4DSeaN00ape4ukPA== From: "BRUNGARD, DEBORAH A (ATTSI)" To: "CCAMP" Subject: [CCAMP] WG document poll for draft-zhang-ccamp-general-constraints-ospf-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: Mon, 21 Feb 2011 17:09:21 -0000 This begins a 2-week poll on adopting this draft as a WG document. Please indicate your support/non-support for this document. Thanks, Deborah and Lou From zhangfatai@huawei.com Tue Feb 22 00:27:27 2011 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 DBC513A6855 for ; Tue, 22 Feb 2011 00:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGOJO6t53veD for ; Tue, 22 Feb 2011 00:27:26 -0800 (PST) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id E88C73A6853 for ; Tue, 22 Feb 2011 00:27:25 -0800 (PST) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH0000NFFIX7N@usaga03-in.huawei.com> for ccamp@ietf.org; Tue, 22 Feb 2011 02:28:09 -0600 (CST) Received: from hp3d061f9287af ([156.106.236.159]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LH0003WPFIVBS@usaga03-in.huawei.com> for ccamp@ietf.org; Tue, 22 Feb 2011 02:28:09 -0600 (CST) Date: Tue, 22 Feb 2011 16:27:54 +0800 From: Fatai Zhang To: "BRUNGARD, DEBORAH A (ATTSI)" , CCAMP Message-id: <003e01cbd26a$6851d1b0$9fec6a9c@hp3d061f9287af> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [CCAMP] WG document poll fordraft-zhang-ccamp-general-constraints-ospf-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: Tue, 22 Feb 2011 08:27:28 -0000 All, Support, as a co-author. Thanks Fatai ----- Original Message ----- From: "BRUNGARD, DEBORAH A (ATTSI)" To: "CCAMP" Sent: Tuesday, February 22, 2011 1:09 AM Subject: [CCAMP] WG document poll fordraft-zhang-ccamp-general-constraints-ospf-ext > This begins a 2-week poll on adopting this draft as a WG document. > Please indicate your support/non-support for this document. > > Thanks, > Deborah and Lou > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From gregb@grotto-networking.com Tue Feb 22 08:24:25 2011 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 21F2F3A68EE for ; Tue, 22 Feb 2011 08:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVFtrSgDYe4X for ; Tue, 22 Feb 2011 08:24:24 -0800 (PST) Received: from mail30c40.carrierzone.com (mail30c40.carrierzone.com [209.235.156.170]) by core3.amsl.com (Postfix) with ESMTP id 110793A6910 for ; Tue, 22 Feb 2011 08:24:23 -0800 (PST) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.125] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail30c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id p1MGP6U2009184 for ; Tue, 22 Feb 2011 16:25:07 GMT Message-ID: <4D63E35F.8020200@grotto-networking.com> Date: Tue, 22 Feb 2011 08:25:03 -0800 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: ccamp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CSC: 0 X-CHA: v=1.1 cv=wD5U+mCNT4tD6izdU8x0HmLJRkSMny8B6TekPf/9FM0= c=1 sm=1 a=Cq6vnHHpfgIA:10 a=8nJEP1OIZ-IA:10 a=OkPnmgdRXU7//wtL+yd+jg==:17 a=48vgC7mUAAAA:8 a=AWN6ivrYtNEGKnU8aHcA:9 a=tjxjlWcaTMbJGihnvXZHgcqtqakA:4 a=wPNLvfGTeEIA:10 a=EgY3od2ZU2QA:10 a=h-I_03WOSDMA:10 a=lZB815dzVvQA:10 a=OkPnmgdRXU7//wtL+yd+jg==:117 Subject: Re: [CCAMP] WG document poll for draft-zhang-ccamp-general-constraints-ospf-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: Tue, 22 Feb 2011 16:24:25 -0000 Support as a co-author. Greg On 2/21/2011 9:09 AM, BRUNGARD, DEBORAH A (ATTSI) wrote: > This begins a 2-week poll on adopting this draft as a WG document. > Please indicate your support/non-support for this document. > > Thanks, > Deborah and Lou > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From iesg-secretary@ietf.org Tue Feb 22 12:38:11 2011 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 538393A68A3; Tue, 22 Feb 2011 12:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfutHgbm4CKR; Tue, 22 Feb 2011 12:38:10 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28DBC3A68F4; Tue, 22 Feb 2011 12:38:10 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110222203810.3417.2849.idtracker@localhost> Date: Tue, 22 Feb 2011 12:38:10 -0800 Cc: ccamp mailing list , Internet Architecture Board , ccamp chair , RFC Editor Subject: [CCAMP] Document Action: 'Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)' to Informational RFC (draft-ietf-ccamp-rwa-wson-framework-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, 22 Feb 2011 20:38:11 -0000 The IESG has approved the following document: - 'Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)' (draft-ietf-ccamp-rwa-wson-framework-12.txt) as an Informational RFC This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ccamp-rwa-wson-framework/ Technical Summary This document 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, it examines Routing and Wavelength Assignment (RWA) of optical paths. This document focuses on topological elements and path selection constraints that are common across different WSON environments, and does not address optical impairments in any depth. Working Group Summary Nothing worth noting. Document Quality This document is an informational framework. Personnel Lou Berger (lberger@labn.net) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. RFC Editor Note Section 4.2 OLD o Management protocols such as NetConf, SNMPv3, CLI, and CORBA. NEW o Management protocols such as NetConf, SNMPv3, and CORBA. o Methods to access configuration and status information such as a command line interface (CLI). END From leeyoung@huawei.com Tue Feb 22 16:54:39 2011 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 03AD13A6767 for ; Tue, 22 Feb 2011 16:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiucVjSvh0mp for ; Tue, 22 Feb 2011 16:54:38 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 0EC0C3A672E for ; Tue, 22 Feb 2011 16:54:38 -0800 (PST) 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 <0LH100JGJP8ANA@usaga04-in.huawei.com> for ccamp@ietf.org; Tue, 22 Feb 2011 18:55:23 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LH100L2XP8AFM@usaga04-in.huawei.com> for ccamp@ietf.org; Tue, 22 Feb 2011 18:55:22 -0600 (CST) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 22 Feb 2011 16:55:18 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Tue, 22 Feb 2011 16:55:21 -0800 Date: Wed, 23 Feb 2011 00:55:21 +0000 From: Leeyoung In-reply-to: X-Originating-IP: [10.124.12.79] To: "BRUNGARD, DEBORAH A (ATTSI)" , CCAMP Message-id: <7AEB3D6833318045B4AE71C2C87E8E1737F3E3@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: WG document poll for draft-zhang-ccamp-general-constraints-ospf-ext Thread-index: AcvR6ilTO2ov9I4DSeaN00ape4ukPABCiejg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [CCAMP] WG document poll for draft-zhang-ccamp-general-constraints-ospf-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: Wed, 23 Feb 2011 00:54:39 -0000 Support Young --- co-author -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of BRUNGARD, DEBORAH A (ATTSI) Sent: Monday, February 21, 2011 11:10 AM To: CCAMP Subject: [CCAMP] WG document poll for draft-zhang-ccamp-general-constraints-ospf-ext This begins a 2-week poll on adopting this draft as a WG document. Please indicate your support/non-support for this document. Thanks, Deborah and Lou _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From takeda.tomonori@lab.ntt.co.jp Wed Feb 23 20:39:00 2011 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 8D4FC3A6968; Wed, 23 Feb 2011 20:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.89 X-Spam-Level: X-Spam-Status: No, score=-98.89 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, 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 lGGJG-92sssF; Wed, 23 Feb 2011 20:38:59 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id 53EAF3A6953; Wed, 23 Feb 2011 20:38:59 -0800 (PST) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.4/8.14.4) with ESMTP id p1O4dlWD007905; Thu, 24 Feb 2011 13:39:47 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 0B17065F9; Thu, 24 Feb 2011 13:39:47 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2.m.ecl.ntt.co.jp [129.60.5.247]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 046BB65F1; Thu, 24 Feb 2011 13:39:47 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.55]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id p1O4dYV4001648; Thu, 24 Feb 2011 13:39:46 +0900 Message-ID: <4D65E0F6.7050004@lab.ntt.co.jp> Date: Thu, 24 Feb 2011 13:39:18 +0900 From: Tomonori TAKEDA User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ccamp@ietf.org, pce@ietf.org, mpls@ietf.org, mpls-tp@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: [CCAMP] iPOP 2011 submission deadline extended to March 4 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 Feb 2011 04:39:00 -0000 (Apologies if you receive multiple copies of this message.) CCAMP, MPLS, MPLS-TP and PCE subscribers, Please find below iPOP 2011 CFP with the extended deadline (March 4th). Tomonori Takeda ------------------------------------------------------------- Call for Presentation 7th International Conference on IP + Optical Network (iPOP 2011) June 2-3, 2011 NEC Tamagawa Plant, Kanagawa, Japan http://www.pilab.jp/ipop2011/ The conference is intended to share among the industry and the academia, the knowledge, new findings, and experience on the state-of-the art of IP and optical networking technologies. It features technical sessions and planned exhibitions. The opportunity to participate is open to all. Important Dates: Submission deadline of one-page abstract: March 4, 2011 (extended) Notification of acceptance: April 4, 2011 Submission deadline of final presentation slides: April 22, 2011 The Technical Program Committee for iPOP 2011 is soliciting presentation proposals for this conference. Protocol design, experiment, theory, implementation, and operational experiences are solicited. The topics of the conference will include but not limited to the following: * GMPLS/ASON technologies * GMPLS Network management, OA&M * Multi-layer network (MLN) / Multi-region network (MRN) * Path Computation Element (PCE), Traffic engineering * Inter-area/Inter-AS network * L1VPN, Bandwidth on Demand, and Photonic Grid * Wavelength Switched Optical Networks (WSON), Routing wavelength assignment, Impairment management * GMPLS-controlled Ethernet Label Switching (GELS) and related Ethernet transport technologies * Carrier Ethernet and MPLS-TP * Photonic Network for NxGN and NwGN * Application with high-bandwidth demand * Testbed, field trial If you wish to submit a topic for consideration, please send an Extended Abstracts of a 400 words and a maximum of 1 page, including figures and diagrams, speaker$B!G(Bs name, affiliation, and contact information to the Technical Program Committee at ipop2011-CFP@pilab.jp. Please see http://www.pilab.jp/ipop2011/ for more details. ---------------------------------------------------------------- From zhang.fei3@zte.com.cn Sun Feb 27 17:33:12 2011 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 C417A3A6961; Sun, 27 Feb 2011 17:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.349 X-Spam-Level: X-Spam-Status: No, score=-100.349 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9JuQv6RYP2F; Sun, 27 Feb 2011 17:33:11 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id D3CD13A695E; Sun, 27 Feb 2011 17:33:10 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205952043691617; Mon, 28 Feb 2011 09:28:59 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 47420.2043691617; Mon, 28 Feb 2011 09:24:55 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p1S1Xsf6038947; Mon, 28 Feb 2011 09:33:54 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) To: ccamp@ietf.org, mpls@ietf.org, mpls-tp@ietf.org MIME-Version: 1.0 X-KeepSent: 3D2BCB7D:7BE0C902-48257845:00045755; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Mon, 28 Feb 2011 09:34:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-02-28 09:33:53, Serialize complete at 2011-02-28 09:33:53 Content-Type: multipart/alternative; boundary="=_alternative 0008966748257845_=" X-MAIL: mse01.zte.com.cn p1S1Xsf6038947 Subject: [CCAMP] draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-03 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, 28 Feb 2011 01:33:13 -0000 This is a multipart message in MIME format. --=_alternative 0008966748257845_= Content-Type: text/plain; charset="US-ASCII" Dear All We just updated the document about the creating of associated bidirectional LSPs, and below is the link: http://tools.ietf.org/id/draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-03.txt Compared with last version, the main changes are about the section of asymmetric associated bidirectional LSP: We used the object UPSTREAM_TSPEC to trigger the peer end to set up the reverse unidirectional LSP in last version, however the application scenario defined in http://tools.ietf.org/html/draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01 is different from here. So a new object called REVERSE_TSPEC is used to replace the UPSTREAM_TSPCE object in this version. The other revisions are structural and editoral in nature, such as complementing more considerations about security, adding one sub-section of informativereference, temporarily moving George from the position of co-authors.... The authors would like to have more feedback from the mailing list before pushing this work forward. Grateful if you could review the document and post comments on the mailing list. Thanks and best regards Fei --=_alternative 0008966748257845_= Content-Type: text/html; charset="US-ASCII"
Dear All

We just updated the document about the creating of associated bidirectional LSPs, and below is the link:

http://tools.ietf.org/id/draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-03.txt
Compared with last version, the main changes are about the section of asymmetric associated bidirectional LSP:

We used the object UPSTREAM_TSPEC to trigger the peer end to set up the reverse unidirectional LSP in last version, however the application scenario defined in http://tools.ietf.org/html/draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-01 is different from here. So a new object called REVERSE_TSPEC is used to replace the UPSTREAM_TSPCE object in this version.

The other revisions are structural and editoral in nature, such as complementing more considerations about security, adding one sub-section of informativereference, temporarily moving George from the position of co-authors....
The authors would like to have more feedback from the mailing list before pushing this work forward.

Grateful if you could review the document and post comments on the mailing list.

 
Thanks and best regards

Fei

--=_alternative 0008966748257845_=-- From vijayc@hcl.com Sun Feb 27 23:30:21 2011 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 5DC543A6AC6 for ; Sun, 27 Feb 2011 23:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.424 X-Spam-Level: X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[AWL=2.029, BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UP1baXRdBT40 for ; Sun, 27 Feb 2011 23:30:20 -0800 (PST) Received: from gws07.hcl.com (gws07.hcl.com [203.105.186.23]) by core3.amsl.com (Postfix) with ESMTP id 569263A6AC5 for ; Sun, 27 Feb 2011 23:30:19 -0800 (PST) Received: from chn-hclin-ht02.CORP.HCL.IN (10.249.64.36) by CHN-HCLIN-EDGE3.HCL.COM (10.249.64.140) with Microsoft SMTP Server id 8.2.254.0; Mon, 28 Feb 2011 13:00:17 +0530 Received: from CHN-HCLT-CASHT2.HCLT.CORP.HCL.IN (10.108.45.28) by chn-hclin-ht02.CORP.HCL.IN (10.249.64.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 28 Feb 2011 13:01:14 +0530 Received: from CHN-HCLT-EVS07.HCLT.CORP.HCL.IN ([fe80::f46b:fdf2:3218:985d]) by CHN-HCLT-CASHT2.HCLT.CORP.HCL.IN ([::1]) with mapi; Mon, 28 Feb 2011 13:01:13 +0530 From: "Vijayanand C - ERS, HCL Tech" To: "ccamp@ietf.org" Date: Mon, 28 Feb 2011 13:01:12 +0530 Thread-Topic: bidir LSP in rfc4803 Thread-Index: AcvXGXlU6/zpjV+LR4e5csqlwu092A== Message-ID: <66E3DDEEA70F0D469D1FFE238526B6ED3E446EE6D1@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_66E3DDEEA70F0D469D1FFE238526B6ED3E446EE6D1CHNHCLTEVS07H_" MIME-Version: 1.0 Subject: [CCAMP] bidir LSP in rfc4803 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, 28 Feb 2011 07:30:21 -0000 --_000_66E3DDEEA70F0D469D1FFE238526B6ED3E446EE6D1CHNHCLTEVS07H_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, How are the two directions of the cross connect of the bidirectional LSP co= rrelated It is not clear in RFC 4803. As per section 5, the cross connects will have the same XC index. " The GMPLS-LSR-STD-MIB module supports bidirectional LSPs as required for GMPLS. A single value of mplsXCIndex is shared by all of the segments for the entire bidirectional LSP. This facilitates a simple reference from [RFC3812] and [RFC480= 2] and makes fate-sharing more obvious. " But as per the example in section 6, the xcindex can be different but the m= plsXCLSPId must be same " In mplsXCTable: { mplsXCIndex =3D 0x01, mplsXCInSegmentIndex =3D 0x00000015, mplsXCOutSegmentIndex =3D 0x00000012, mplsXCLspId =3D 0x0102 -- unique ID mplsXCLabelStackIndex =3D 0x00, -- only a single outgoing label mplsXCRowStatus =3D createAndGo(4) } In mplsXCTable: { mplsXCIndex =3D 0x02, mplsXCInSegmentIndex =3D 0x00000016, mplsXCOutSegmentIndex =3D 0x00000013, mplsXCLspId =3D 0x0102 -- unique ID mplsXCLabelStackIndex =3D 0x00, -- only a single outgoing label mplsXCRowStatus =3D createAndGo(4) } " Will the mplsXCindex be same or different, please clarify. Regards Vijay ________________________________ ::DISCLAIMER:: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliate= s. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect t= he opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender immedia= tely. Before opening any mail and attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- --_000_66E3DDEEA70F0D469D1FFE238526B6ED3E446EE6D1CHNHCLTEVS07H_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All,

 

How are the two directions of the cross connect of the bidirec= tional LSP correlated

It is not clear in RFC 4803.

 

As per section 5, the cross connects will have the same XC ind= ex.

"

The GMPLS-LSR-STD-MIB module supports bidirectional LSPs as re= quired
&= nbsp;  for GMPLS.  A single value of mplsXCIndex is shared by all= of the
&= nbsp;  segments for the entire bidirectional LSP.  This facilitat= es a simple
&= nbsp;  reference from [RFC3812] and [RFC4802] and makes fate-sharing more
&= nbsp;  obvious.
&= quot;

 

But as per the example in section 6, the xcindex can be differ= ent but the mplsXCLSPId must be same

 

" In mplsXCTable:<= br> &= nbsp;  {
&= nbsp;     mplsXCIndex     &nbs= p;          =3D 0x01,
&= nbsp;     mplsXCInSegmentIndex    &= nbsp;  =3D 0x00000015,
&= nbsp;     mplsXCOutSegmentIndex    =   =3D 0x00000012,
&= nbsp;     mplsXCLspId     &nbs= p;          =3D 0x0102 -- uniq= ue ID
&= nbsp;     mplsXCLabelStackIndex    =   =3D 0x00, -- only a single outgoing label
&= nbsp;     mplsXCRowStatus     =        =3D createAndGo(4)
&= nbsp;  }

&= nbsp;  In mplsXCTable:
&= nbsp;  {
&= nbsp;     mplsXCIndex     &nbs= p;          =3D 0x02,
&= nbsp;     mplsXCInSegmentIndex    &= nbsp;  =3D 0x00000016,
&= nbsp;     mplsXCOutSegmentIndex    =   =3D 0x00000013,
&= nbsp;     mplsXCLspId     &nbs= p;          =3D 0x0102 -- uniq= ue ID
&= nbsp;     mplsXCLabelStackIndex    =   =3D 0x00, -- only a single outgoing label
&= nbsp;     mplsXCRowStatus     =        =3D createAndGo(4)
&= nbsp;  }
&= quot;

 

 

Will the mplsXCindex be same or different, please clarify.

 

 

Regards=

Vijay


::DISCLAIMER::
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliate= s. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect t= he opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender immedia= tely. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------
 --_000_66E3DDEEA70F0D469D1FFE238526B6ED3E446EE6D1CHNHCLTEVS07H_-- From Attila.Takacs@ericsson.com Mon Feb 28 06:48:33 2011 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 0E9963A6C19 for ; Mon, 28 Feb 2011 06:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7IBE7K8Na-h for ; Mon, 28 Feb 2011 06:48:31 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 09CA43A6C15 for ; Mon, 28 Feb 2011 06:48:30 -0800 (PST) X-AuditID: c1b4fb39-b7c6dae0000023f2-8f-4d6bb5fa9999 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FD.FB.09202.AF5BB6D4; Mon, 28 Feb 2011 15:49:30 +0100 (CET) Received: from ESESSCMS0365.eemea.ericsson.se ([169.254.1.161]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 28 Feb 2011 15:49:30 +0100 From: Attila Takacs To: "Vijayanand C - ERS, HCL Tech" , "ccamp@ietf.org" Date: Mon, 28 Feb 2011 15:49:29 +0100 Thread-Topic: bidir LSP in rfc4803 Thread-Index: AcvXGXlU6/zpjV+LR4e5csqlwu092AAOKXfA Message-ID: <6477E10CC7D76444A479B9AC31F262A9DD9D0C93@ESESSCMS0365.eemea.ericsson.se> References: <66E3DDEEA70F0D469D1FFE238526B6ED3E446EE6D1@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> In-Reply-To: <66E3DDEEA70F0D469D1FFE238526B6ED3E446EE6D1@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6477E10CC7D76444A479B9AC31F262A9DD9D0C93ESESSCMS0365eem_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] bidir LSP in rfc4803 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, 28 Feb 2011 14:48:33 -0000 --_000_6477E10CC7D76444A479B9AC31F262A9DD9D0C93ESESSCMS0365eem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vijay, Thanks for pointing out the MIB aspects, this is indeed a bit lagging behin= d. However, initial work on TP specific MIB has been started recently: http://= tools.ietf.org/id/draft-vkst-mpls-tp-te-mib-00.txt discusses bidirectional = LSPs and I think the asymmetric bandwidth option should be addressed in tha= t document as it goes along. Attila ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of V= ijayanand C - ERS, HCL Tech Sent: Monday, February 28, 2011 8:31 AM To: ccamp@ietf.org Subject: [CCAMP] bidir LSP in rfc4803 Hello All, How are the two directions of the cross connect of the bidirectional LSP co= rrelated It is not clear in RFC 4803. As per section 5, the cross connects will have the same XC index. " The GMPLS-LSR-STD-MIB module supports bidirectional LSPs as required for GMPLS. A single value of mplsXCIndex is shared by all of the segments for the entire bidirectional LSP. This facilitates a simple reference from [RFC3812] and [RFC480= 2] and makes fate-sharing more obvious. " But as per the example in section 6, the xcindex can be different but the m= plsXCLSPId must be same " In mplsXCTable: { mplsXCIndex =3D 0x01, mplsXCInSegmentIndex =3D 0x00000015, mplsXCOutSegmentIndex =3D 0x00000012, mplsXCLspId =3D 0x0102 -- unique ID mplsXCLabelStackIndex =3D 0x00, -- only a single outgoing label mplsXCRowStatus =3D createAndGo(4) } In mplsXCTable: { mplsXCIndex =3D 0x02, mplsXCInSegmentIndex =3D 0x00000016, mplsXCOutSegmentIndex =3D 0x00000013, mplsXCLspId =3D 0x0102 -- unique ID mplsXCLabelStackIndex =3D 0x00, -- only a single outgoing label mplsXCRowStatus =3D createAndGo(4) } " Will the mplsXCindex be same or different, please clarify. Regards Vijay ________________________________ ::DISCLAIMER:: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliate= s. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect t= he opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender immedia= tely. Before opening any mail and attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- --_000_6477E10CC7D76444A479B9AC31F262A9DD9D0C93ESESSCMS0365eem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Vijay,<= /FONT>
=  
Thanks for poi= nting=20 out the MIB aspects, this is indeed a bit lagging behind.=20
=  
However, = initial=20 work on TP specific MIB has been started recently:=20 http://t= ools.ietf.org/id/draft-vkst-mpls-tp-te-mib-00.txt discusses=20 bidirectional LSPs and I think the asymmetric bandwidth option should be=20 addressed in that document as it goes along.
 
Attila

From: ccamp-bounces@ietf.org=20 [mailto:ccamp-bounces@ietf.org] On Behalf Of Vijayanand C - ERS, HCL= =20 Tech
Sent: Monday, February 28, 2011 8:31 AM
To:=20 ccamp@ietf.org
Subject: [CCAMP] bidir LSP in=20 rfc4803

Hello=20 All,

 

How=20 are the two directions of the cross connect of the bidirectional LSP=20 correlated

It is=20 not clear in RFC 4803.

 

As per=20 section 5, the cross connects will have the same XC index.

"

The=20 GMPLS-LSR-STD-MIB module supports bidirectional LSPs as=20 required
   for GMPLS.  = A=20 single value of mplsXCIndex is shared by all of the
   segments for the = entire=20 bidirectional LSP.  This facilitates a simple
   reference from=20 [RFC3812] and [RFC4802] and makes fate-sharing=20 more
  =20 obvious.
"

 

But as=20 per the example in section 6, the xcindex can be different but the mplsXCLS= PId=20 must be same

 

" In=20 mplsXCTable:
  =20 {
     = =20 mplsXCIndex          &nbs= p;    =20 =3D 0x01,
     = =20 mplsXCInSegmentIndex       =3D=20 0x00000015,
     = =20 mplsXCOutSegmentIndex      =3D=20 0x00000012,
     = =20 mplsXCLspId          &nbs= p;    =20 =3D 0x0102 -- unique ID
     = =20 mplsXCLabelStackIndex      =3D 0x00, -- only a sin= gle=20 outgoing label
     = =20 mplsXCRowStatus          =  =20 =3D createAndGo(4)
  =20 }

   In=20 mplsXCTable:
  =20 {
     = =20 mplsXCIndex          &nbs= p;    =20 =3D 0x02,
     = =20 mplsXCInSegmentIndex       =3D=20 0x00000016,
     = =20 mplsXCOutSegmentIndex      =3D=20 0x00000013,
     = =20 mplsXCLspId          &nbs= p;    =20 =3D 0x0102 -- unique ID
     = =20 mplsXCLabelStackIndex      =3D 0x00, -- only a sin= gle=20 outgoing label
     = =20 mplsXCRowStatus          =  =20 =3D createAndGo(4)
  =20 }
"

 

 

Will=20 the mplsXCindex be same or different, please clarify.

 

 

Regards=

Vijay


::DISCLAIMER::
------------------------------------------------= -----------------------------------------------------------------------
=
The=20 contents of this e-mail and any attachment(s) are confidential and intended= for=20 the named recipient(s) only.
It shall not attach any liability on the=20 originator or HCL or its affiliates. Any views or opinions presented in
= this=20 email are solely those of the author and may not necessarily reflect the=20 opinions of HCL or its affiliates.
Any form of reproduction, disseminati= on,=20 copying, disclosure, modification, distribution and / or publication of
= this=20 message without the prior written consent of the author of this e-mail is=20 strictly prohibited. If you have
received this email in error please del= ete=20 it and notify the sender immediately. Before opening any mail and
attach= ments=20 please check them for viruses and=20 defect.

------------------------------------------------------------= -----------------------------------------------------------
 --_000_6477E10CC7D76444A479B9AC31F262A9DD9D0C93ESESSCMS0365eem_-- From huawei.danli@huawei.com Sun Feb 27 16:15:06 2011 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 8286E3A6A57 for ; Sun, 27 Feb 2011 16:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 P4ORSoFNB8dP for ; Sun, 27 Feb 2011 16:15:05 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 565AA3A6A56 for ; Sun, 27 Feb 2011 16:15:05 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHA00M0OWQHDY@szxga05-in.huawei.com> for ccamp@ietf.org; Mon, 28 Feb 2011 08:15:53 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHA005NAWQH71@szxga05-in.huawei.com> for ccamp@ietf.org; Mon, 28 Feb 2011 08:15:53 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 28 Feb 2011 08:15:50 +0800 Received: from l00037133 (10.70.77.125) by SZXEML402-HUB.china.huawei.com (10.82.67.32) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 28 Feb 2011 08:15:52 +0800 Date: Mon, 28 Feb 2011 08:15:53 +0800 From: Dan Li X-Originating-IP: [10.70.77.125] To: "BRUNGARD, DEBORAH A (ATTSI)" , CCAMP Message-id: <000d01cbd6dc$a992a3e0$7d4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: X-Mailman-Approved-At: Mon, 28 Feb 2011 06:57:02 -0800 Subject: Re: [CCAMP] WG document poll fordraft-zhang-ccamp-general-constraints-ospf-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: Mon, 28 Feb 2011 00:24:12 -0000 Yes, support! Dan ----- Original Message ----- From: "BRUNGARD, DEBORAH A (ATTSI)" To: "CCAMP" Sent: Tuesday, February 22, 2011 1:09 AM Subject: [CCAMP] WG document poll fordraft-zhang-ccamp-general-constraints-ospf-ext > This begins a 2-week poll on adopting this draft as a WG document. > Please indicate your support/non-support for this document. > > Thanks, > Deborah and Lou > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From ma-miyazawa@kddilabs.jp Mon Feb 28 07:31:30 2011 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 7596E3A69F3; Mon, 28 Feb 2011 07:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1KiYH-8z2f0; Mon, 28 Feb 2011 07:31:28 -0800 (PST) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by core3.amsl.com (Postfix) with ESMTP id 028123A693D; Mon, 28 Feb 2011 07:31:27 -0800 (PST) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 647BE1748218; Tue, 1 Mar 2011 00:32:26 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atpalwl61GSo; Tue, 1 Mar 2011 00:32:25 +0900 (JST) Received: from platinum.inc.kddilabs.jp (platinum.inc.kddilabs.jp [IPv6:2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id C14FC1748213; Tue, 1 Mar 2011 00:32:25 +0900 (JST) Received: from miyazawaPC (ebisu.kddilabs.jp [IPv6:2001:200:601:11::214]) by platinum.inc.kddilabs.jp (Postfix) with ESMTP id 781C3578063; Tue, 1 Mar 2011 00:32:25 +0900 (JST) From: "Masanori Miyazawa" To: "'Joan Cucchiara'" , , "'MIB Doctors (E-mail)'" , "'Tomohiro Otani'" , , "'Thomas D. Nadeau'" References: <00ce01cbb34d$e6aa1130$6501a8c0@JoanPC> In-Reply-To: <00ce01cbb34d$e6aa1130$6501a8c0@JoanPC> Date: Tue, 1 Mar 2011 00:32:25 +0900 Message-ID: <012b01cbd75c$b36d5100$1a47f300$@jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuzTjblYmPrL3F6QjW5rXXyAGGNPAkDVr8A Content-Language: ja Cc: "'Dan Romascanu \(E-mail\)'" Subject: Re: [CCAMP] MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07 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, 28 Feb 2011 15:31:30 -0000 Hi, Joan Thank you for your comments. In accordance with your comments, I am revising the documents. Please see our answer to your comments as below and let us know if you have any question With best regards, Masanori DOCUMENT COMMENTS ------------------------------------- *) NIT: Does not strip cleanly with smicPRO's mstrip. (This does not have to be fixed for MIB Dr. purposes, only mention as an fyi.) *) Author contact info needs to be updated. "Update in next version" *) Dates and copyright need to be updated " Update in next version " *) RFC references probably need to be updated. RFC3784 was obsoleted by RFC5305 RFC4205 was obsoleted by RFC5307 " Update in next version " IANA-GMPLS-TC-MIB needs to be added to Informative Reference Section. " Update in next version " *) 2. Introduction Since this document supports both OSPFv2 and OSPFv3, please say this explicitly. "Modify in next version" *) The following 2 RFCs should be referenced also. a. OSPFv3 MIB is defined in rfc5643 b. TE extensions to OSPFv3 are described in RFC5329 " Modify in next version " *) 3.3 Acronyms These should be in alphabetical order (or some order that is defined at the beginning of this subsection.) Should include TED: Traffic Engineering Database " Modify in next version " *) Section 4. Motivations The motivation statement leads one to believe that this document will provide "for the management of all of the extensions to the OSPF and ISIS protocol.". There are 2 inconsistencies here: a) Since this is a read-only MIB, (no configuration) then the statement should be revised because management includes configuration. b) As previously mentioned, the use of OSPF and then references to OSPFv2 is misleading, please use OSPFv2, and include OSPFv3 along with relevant documents. " Modify in next version as shown below" The existing OSPFv2, OSPFv3, ISIS, MPLS and GMPLS MIBs do not provide for the management interface to retrieve topology information for the MPLS and GMPLS network. *) Section 5.1 s/information of/information for/ " Modify in next version " *) Section 5.3 s/This is also independently utilized,because/Also, this is utilized independently because/ "Modified" *) Section 5.4 This is referred to as Switch Capable and also as Switching Capability, please be consistent. If SwCap is supposed to be Switching Capability, then please use that Switching Capablity consistently. " We use Switching Capability consistently in this document." COMMENTS ON MIB MODULE -------------------------------------------- *) TEXTUAL-CONVENTIONS The names of these TCs are already used in the OSPFv2 MIB and while this may have been done intentionally, would prefer a TED specific name. For example: RouterID, AreaID, LinkStateID are used in OSPFv2-MIB (RFC4750) Could these be renamed to be prefixed with "Ted" and suffixed with "TC", such as TedRouterIdTC" ? " Modify in next version " *) tedCreateDeleteNotificationMaxRate and tedStatusChangeNotificationMaxRate a) Why are these objects not located closer to the Notifications? b) tedCreateDeleteNotificationMaxRate, has a DEFVAL {0}. The DESCRIPTION clause does not indicate that 0 has a special value (as it does for tedStatusChangeNotificationMaxRate, so just want to check on this? Do you really mean 0 here? "DEFVAL was deleted from tedCreateDeleteNotificationMaxRate" *) tedInfoStatus object I think there is still some confusion about my request for status/state information. Obviously, if there are rows in these tables, then the MIB has been configured by some means other than SNMP, and granted notifications are sent (unless they are dropped due to throttling or lost), but what is the Operational Status link? The RowPointer object, tedLinkInformationData, might provide this information, however, the DESCRIPTION clause makes it sound completely optional since it looks like 0.0 can be entered under any circumstance, so again, I have to ask, how is an operator supposed to know if the TE link is acting as intended? If tedLinkInformationData is supposed to provide this, then it needs to be rewritten to be mandatory. That means that there are dependencies on other MIBs also. That is unclear in this document. In summary, tedInfoStatus object does not provide any additional information, as I can see if the MIB is populated. What I'm asking for is Operational Status/State information. Please discuss. "Thank you for your comment. We think the definition of tedInfosStatus in previous version was wrong, as you indeicated . It took into account only a state/status of this MIB itself, not link information. In order to take into account the operational status of TE link, we think it is necessary to create new object such as, for example, "tedLinkState" in tedTable as shown below. If you have comments, please let us know. " tedLinkState OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-only STATUS current DESCRIPTION " " ::={ tedEntry X } *) tedSwCapSwitchingType Please rename to tedSwCapType. " Modify in next version " *) tedNotificationAreaId and tedNotificationRouterId Not sure why these are needed. Couldn't you include an object from the tedTable (such as tedLinkInformationSource) rather than have these accessible for Notify objects. Seems like extra work on all parts and not sure I see the advantage when you already have this info in a table. Please discuss. " In version 6 of ted mib, tedAreaId, tedRouterId and tedLinkStateId were utilzed as the Index of notification because it is useful to treat as the notification with unique value by using combination of these objects. But, it cause some error on SMICngPro as shown below. Therefore, we decided to utilize new objects such as tedNotificationAreaId, tedNotificationRouteId and tedNotificationLinkStateId. We think we want to use tedAreaId, tedRouterId and tedLinkStateId as the index of notification again. What do you think?" OUTPUT from SMICngPRO --------------------- W: f(TED-MIB.my), (777,10) Variable "tedAreaId" in notification "tedStatusChange" is an index for a table W: f(TED-MIB.my), (777,21) Variable "tedRouterId" in notification "tedStatusChange" is an index for a table W: f(TED-MIB.my), (777,34) Variable "tedLinkStateId" in notification "tedStatusChange" is an index for a table " *) 8. Security Considerations s/read-write../read-write./ " Modify in next version " *) 10.1 Normative References a) Some of the Informative References should probably moved to Normative, specifically, any of the MIB docs that are IMPORTED or appear in a REFERENCE clause. " Modify in next version " *) 10.2 Informative References a) NIT: should be listed in increasing RFC Order. " Modify in next version " > -----Original Message----- > From: Joan Cucchiara [mailto:jcucchiara@mindspring.com] > Sent: Friday, January 14, 2011 3:16 AM > To: ccamp@ietf.org; MIB Doctors (E-mail); Tomohiro Otani; Masanori > Miyazawa; ke-kumaki@kddilabs.jp; Thomas D. Nadeau > Cc: Joan Cucchiara; Dan Romascanu (E-mail) > Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-ted-mib-07 > > > Hi Masonori, > > Thank you for the new version of this document. There were many good > updates, particularly, the Conformance section. > > Please see following comments. > > Thanks, > -Joan > > > > COMPILER RESULTS > ------------------------------ > * MIB compiles cleanly with smicngPRO > > * MIB compiles cleanly with smiLint > > > DOCUMENT COMMENTS > ------------------------------------- > *) NIT: Does not strip cleanly with smicPRO's mstrip. > (This does not have to be fixed for MIB Dr. purposes, > only mention as an fyi.) > > > *) Author contact info needs to be updated. > > *) Dates and copyright need to be updated > > *) RFC references probably need to be updated. > > RFC3784 was obsoleted by RFC5305 > RFC4205 was obsoleted by RFC5307 > > IANA-GMPLS-TC-MIB needs to be added to Informative Reference Section. > > > > > *) 2. Introduction > > Since this document supports both OSPFv2 and OSPFv3, please > say this explicitly. > > *) The following 2 RFCs should be referenced also. > > a. OSPFv3 MIB is defined in rfc5643 > b. TE extensions to OSPFv3 are described in RFC5329 > > > > *) 3.3 Acronyms > > These should be in alphabetical order (or some order that > is defined at the beginning of this subsection.) > > Should include TED: Traffic Engineering Database > > > > *) Section 4. Motivations > > The motivation statement leads one to believe that this > document will provide "for the management of all of the > extensions to the OSPF and ISIS protocol.". > > There are 2 inconsistencies here: > a) Since this is a read-only MIB, (no configuration) then the > statement should be revised because management includes configuration. > b) As previously mentioned, the use of OSPF and then references > to OSPFv2 is misleading, please use OSPFv2, and include OSPFv3 > along with relevant documents. > > > *) Section 5.1 > > s/information of/information for/ > > > *) Section 5.3 > > s/This is also independently utilized,because/Also, this is utilized > independently > because/ > > > *) Section 5.4 > > This is referred to as Switch Capable and also > as Switching Capability, please be consistent. If SwCap is > supposed to be Switching Capability, then please use that > Switching Capablity consistently. > > > > > > COMMENTS ON MIB MODULE > -------------------------------------------- > > > *) TEXTUAL-CONVENTIONS > > The names of these TCs are already used in the OSPFv2 MIB > and while this may have been done intentionally, would prefer > a TED specific name. > > For example: > > RouterID, AreaID, LinkStateID are used in OSPFv2-MIB (RFC4750) > > Could these be renamed to be prefixed with "Ted" > and suffixed with "TC", such as TedRouterIdTC" ? > > > > > *) tedCreateDeleteNotificationMaxRate and > tedStatusChangeNotificationMaxRate > > a) Why are these objects not located closer to the Notifications? > > b) tedCreateDeleteNotificationMaxRate, has a DEFVAL {0}. The DESCRIPTION > clause > does not indicate that 0 has a special value (as it does for > tedStatusChangeNotificationMaxRate, > so just want to check on this? Do you really mean 0 here? > > *) tedInfoStatus object > > I think there is still some confusion about my request for status/state > information. > Obviously, if there are rows in these tables, then > the MIB has been configured by some means other than SNMP, and granted > notifications are sent (unless > they are dropped due to throttling or lost), but what is the Operational > Status > link? > > The RowPointer object, tedLinkInformationData, might provide this > information, however, > the DESCRIPTION clause makes it sound completely optional since it looks > like 0.0 > can be entered under any circumstance, so again, I have to ask, how is an > operator > supposed to know if the TE link is acting as intended? > > If tedLinkInformationData is supposed to provide this, then it needs to > be > rewritten to > be mandatory. That means that there are dependencies on other MIBs also. > That is > unclear in this document. > > In summary, tedInfoStatus object does not provide any additional > information, as > I can see if the MIB is populated. What I'm asking for is Operational > Status/State > information. > > > Please discuss. > > > *) tedSwCapSwitchingType > > Please rename to tedSwCapType. > > > > > *) tedNotificationAreaId and tedNotificationRouterId > > Not sure why these are needed. Couldn't you include > an object from the tedTable (such as tedLinkInformationSource) > rather than have these accessible for Notify objects. Seems like > extra work on all parts and not sure I see the advantage when > you already have this info in a table. > > Please discuss. > > > > *) 8. Security Considerations > > s/read-write../read-write./ > > *) 10.1 Normative References > > a) Some of the Informative References should > probably moved to Normative, specifically, any of the MIB > docs that are IMPORTED or appear in a REFERENCE clause. > > > *) 10.2 Informative References > > a) NIT: should be listed in increasing RFC Order. > From Internet-Drafts@ietf.org Mon Feb 28 09:00:03 2011 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 29B283A6C38; Mon, 28 Feb 2011 09:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id st1E1NBfxNZ8; Mon, 28 Feb 2011 09:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6DB3A6C35; Mon, 28 Feb 2011 09:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110228170001.6036.48758.idtracker@localhost> Date: Mon, 28 Feb 2011 09:00:01 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-wson-signal-compatibility-ospf-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: Mon, 28 Feb 2011 17:00: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 : OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks Author(s) : Y. Lee, G. Bernstein Filename : draft-ietf-ccamp-wson-signal-compatibility-ospf-03.txt Pages : 11 Date : 2011-02-28 This document provides GMPLS OSPF routing enhancements to support signal compatibility constraints associated with WSON network elements. These routing enhancements are required in common optical or hybrid electro-optical networks where not all of the optical signals in the network are compatible with all network elements participating in the network. This compatibility constraint model is applicable to common optical or hybrid electro optical systems such as OEO switches, regenerators, and wavelength converters since such systems can be limited to processing only certain types of WSON signals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-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-wson-signal-compatibility-ospf-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-28085614.I-D@ietf.org> --NextPart-- From leeyoung@huawei.com Mon Feb 28 09:16:43 2011 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 04BB23A6B2F for ; Mon, 28 Feb 2011 09:16:43 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwxB2KuKGhbe for ; Mon, 28 Feb 2011 09:16:42 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 1AB9F3A69FC for ; Mon, 28 Feb 2011 09:16:42 -0800 (PST) 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 <0LHC00HR881ISS@usaga04-in.huawei.com> for ccamp@ietf.org; Mon, 28 Feb 2011 11:17:42 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LHC00DT981HUJ@usaga04-in.huawei.com> for ccamp@ietf.org; Mon, 28 Feb 2011 11:17:42 -0600 (CST) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 28 Feb 2011 09:17:39 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Mon, 28 Feb 2011 09:17:41 -0800 Date: Mon, 28 Feb 2011 17:17:40 +0000 From: Leeyoung X-Originating-IP: [10.124.12.79] To: CCAMP Message-id: <7AEB3D6833318045B4AE71C2C87E8E17380A12@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_rrG9z6krV+L66Gsbk1qeFQ)" Content-language: en-US Accept-Language: en-US Thread-topic: [CCAMP] I-D Action:draft-ietf-ccamp-wson-signal-compatibility-ospf-03.txt Thread-index: AQHL12nk88GP3Z5qdkWMouckuMzSoJQXJT8g X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Subject: [CCAMP] FW: I-D Action:draft-ietf-ccamp-wson-signal-compatibility-ospf-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: Mon, 28 Feb 2011 17:16:43 -0000 --Boundary_(ID_rrG9z6krV+L66Gsbk1qeFQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, This update includes a new Top Level Node TLV, "Optical Node Property TLV" to carry all WSON specific node information (such as OEO/REG/WC resource blocks) and signal compatibility constraints. Regards, Young & Greg -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, February 28, 2011 11:00 AM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-wson-signal-compatibility-ospf-03.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 : OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks Author(s) : Y. Lee, G. Bernstein Filename : draft-ietf-ccamp-wson-signal-compatibility-ospf-03.txt Pages : 11 Date : 2011-02-28 This document provides GMPLS OSPF routing enhancements to support signal compatibility constraints associated with WSON network elements. These routing enhancements are required in common optical or hybrid electro-optical networks where not all of the optical signals in the network are compatible with all network elements participating in the network. This compatibility constraint model is applicable to common optical or hybrid electro optical systems such as OEO switches, regenerators, and wavelength converters since such systems can be limited to processing only certain types of WSON signals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-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. --Boundary_(ID_rrG9z6krV+L66Gsbk1qeFQ) Content-type: message/external-body; name=draft-ietf-ccamp-wson-signal-compatibility-ospf-03.url Content-transfer-encoding: base64 Content-disposition: attachment; filename=draft-ietf-ccamp-wson-signal-compatibility-ospf-03.url; size=115; creation-date="Mon, 28 Feb 2011 17:06:52 GMT"; modification-date="Mon, 28 Feb 2011 17:06:52 GMT" Content-description: draft-ietf-ccamp-wson-signal-compatibility-ospf-03.url W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWNjYW1wLXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0wMy50eHQN Cg== --Boundary_(ID_rrG9z6krV+L66Gsbk1qeFQ) Content-id: Content-type: text/plain; name=ATT00001.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ATT00001.txt; size=130; creation-date="Mon, 28 Feb 2011 17:06:52 GMT"; modification-date="Mon, 28 Feb 2011 17:06:52 GMT" Content-description: ATT00001.txt _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --Boundary_(ID_rrG9z6krV+L66Gsbk1qeFQ)-- From Internet-Drafts@ietf.org Mon Feb 28 17:00:02 2011 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 7745E3A6D33; Mon, 28 Feb 2011 17:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtEWDmurZLQt; Mon, 28 Feb 2011 17:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8B63A6D2C; Mon, 28 Feb 2011 17:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110301010001.23849.30654.idtracker@localhost> Date: Mon, 28 Feb 2011 17:00:01 -0800 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-rwa-info-10.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 01: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 : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks Author(s) : G. Bernstein Filename : draft-ietf-ccamp-rwa-info-10.txt Pages : 26 Date : 2011-02-28 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. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-rwa-info-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-28165400.I-D@ietf.org> --NextPart-- From zhangguoying2010@gmail.com Mon Feb 28 20:30:35 2011 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 BA11D3A6DAA for ; Mon, 28 Feb 2011 20:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 59z+GdIiHSOa for ; Mon, 28 Feb 2011 20:30:35 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id A9CA43A698D for ; Mon, 28 Feb 2011 20:30:34 -0800 (PST) Received: by yic13 with SMTP id 13so37323yic.31 for ; Mon, 28 Feb 2011 20:31:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:references:subject:message-id :x-mailer:mime-version:content-type; bh=e0o4tF2OyesZZ19d5oOQwtbT49t64Orqpveebz/HmHE=; b=WYWxD2XCv/4KmFucvECYkif+IXLXSNJLqPki8lkcnINAnsw5UVsH7ciT2W8JrcPMJI FdBNAB9lnnkzcw4d7kfty9DM6CzWCcBWzTRb5WtJ/d6d5HI0vfRQlEFDbWRSJhkDCPdC +QmrXxKOZgRlZGtzO8nNaP9DCzj/NIY/TrmzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:references:subject:message-id:x-mailer:mime-version :content-type; b=G76pb267Zm8VDDpWuAOl5YdbEGxaTdchJjAvUf3CW894cu3UVn0GDC6KDCYZuIHLeY LhPVr07BInQTxbETm/xRmWVEGU3KZ4kV69b1IbxkUfO9RjDvc1pF39tHpLlrBHM+yyhT lZd1xLkoZrJ/Ept0eX6LEqcNFXHGGGsZmiiyg= Received: by 10.100.24.22 with SMTP id 22mr1008743anx.263.1298953896382; Mon, 28 Feb 2011 20:31:36 -0800 (PST) Received: from wenyuzhao (99-113-68-102.lightspeed.frokca.sbcglobal.net [99.113.68.102]) by mx.google.com with ESMTPS id e24sm5933578ana.2.2011.02.28.20.31.34 (version=SSLv3 cipher=OTHER); Mon, 28 Feb 2011 20:31:35 -0800 (PST) Date: Mon, 28 Feb 2011 20:31:39 -0800 From: "zhangguoying" To: "BRUNGARD, DEBORAH A (ATTSI)" , "CCAMP" References: Message-ID: <201102282031379069496@gmail.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon004414683522_=====" Subject: Re: [CCAMP] WG document poll fordraft-zhang-ccamp-general-constraints-ospf-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: Tue, 01 Mar 2011 04:30:35 -0000 This is a multi-part message in MIME format. --=====003_Dragon004414683522_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Yes, Support as a co-author. Guoying 2011-02-28 zhangguoying [CCAMP] WG document poll fordraft-zhang-ccamp-general-constraints-ospf-ext This begins a 2-week poll on adopting this draft as a WG document. Please indicate your support/non-support for this document. Thanks, Deborah and Lou _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --=====003_Dragon004414683522_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC42MDAwLjE3MDYzIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpF OiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJv bWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IEZPTlQtU0laRTogMTAuNXB0OyBNQVJHSU46IDBjbSAwY20g MHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1c3RpZnkN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtV0VJR0hUOiBub3JtYWw7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNUWUxFOiBub3JtYWw7 IEZPTlQtRkFNSUxZOiBWZXJkYW5hOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hIj4NCjxESVY+PEZP TlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPlllcywgU3VwcG9ydCBhcyBhIA0K Y28tYXV0aG9yLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkd1b3lpbmcg PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jYzBjMGMwIHNp emU9Mj4yMDExLTAyLTI4IDwvRk9OVD48L0RJVj48Rk9OVCANCmZhY2U9VmVyZGFuYSBjb2xvcj0j MDAwMDgwIHNpemU9Mj4NCjxIUiBzdHlsZT0iV0lEVEg6IDEyMnB4OyBIRUlHSFQ6IDJweCIgYWxp Z249bGVmdCBTSVpFPTI+DQo8L0ZPTlQ+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0j YzBjMGMwIHNpemU9Mj48U1BBTj56aGFuZ2d1b3lpbmc8L1NQQU4+IA0KPC9GT05UPjwvRElWPjxG T05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj4NCjxIUj4NCjwvRk9OVD4NCjxE SVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj4mbmJzcDtbQ0NBTVBdIFdHIGRvY3VtZW50IHBv bGwgDQpmb3JkcmFmdC16aGFuZy1jY2FtcC1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtZXh0IDwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48L0ZPTlQ+IDwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPg0KPERJVj5UaGlzJm5ic3A7YmVnaW5z Jm5ic3A7YSZuYnNwOzItd2VlayZuYnNwO3BvbGwmbmJzcDtvbiZuYnNwO2Fkb3B0aW5nJm5ic3A7 dGhpcyZuYnNwO2RyYWZ0Jm5ic3A7YXMmbmJzcDthJm5ic3A7V0cmbmJzcDtkb2N1bWVudC48L0RJ Vj4NCjxESVY+UGxlYXNlJm5ic3A7aW5kaWNhdGUmbmJzcDt5b3VyJm5ic3A7c3VwcG9ydC9ub24t c3VwcG9ydCZuYnNwO2ZvciZuYnNwO3RoaXMmbmJzcDtkb2N1bWVudC48L0RJVj4NCjxESVY+PC9E SVY+DQo8RElWPlRoYW5rcyw8L0RJVj4NCjxESVY+RGVib3JhaCZuYnNwO2FuZCZuYnNwO0xvdTwv RElWPg0KPERJVj48L0RJVj4NCjxESVY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188L0RJVj4NCjxESVY+Q0NBTVAmbmJzcDttYWlsaW5nJm5ic3A7bGlzdDwv RElWPg0KPERJVj5DQ0FNUEBpZXRmLm9yZzwvRElWPg0KPERJVj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wPC9ESVY+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+ DQo= --=====003_Dragon004414683522_=====-- From xuyunbin@mail.ritt.com.cn Mon Feb 28 20:37:32 2011 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 5EEA13A6DAC for ; Mon, 28 Feb 2011 20:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.706 X-Spam-Level: X-Spam-Status: No, score=0.706 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zbq3kQ9ARfuv for ; Mon, 28 Feb 2011 20:37:31 -0800 (PST) Received: from mail.ritt.com.cn (unknown [114.242.138.101]) by core3.amsl.com (Postfix) with SMTP id CAC233A6DAB for ; Mon, 28 Feb 2011 20:37:30 -0800 (PST) Received: from 114.247.10.123 by mail.ritt.com.cn([114.242.138.101]) with SMTP id S26B4F4C684; Tue, 01 Mar 2011 12:35:47 +0800 Date: Tue, 1 Mar 2011 12:38:19 +0800 From: "xuyunbin" To: "BRUNGARD, DEBORAH A (ATTSI)" , "CCAMP" References: , <201102282031379069496@gmail.com> Message-ID: <201103011238121569392@mail.ritt.com.cn> X-mailer: Foxmail 6, 15, 201, 23 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon344143370341_=====" Subject: Re: [CCAMP] WG document pollfordraft-zhang-ccamp-general-constraints-ospf-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: Tue, 01 Mar 2011 04:37:32 -0000 This is a multi-part message in MIME format. --=====003_Dragon344143370341_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit yes, support. YUNBIN XU [CCAMP] WG document poll fordraft-zhang-ccamp-general-constraints-ospf-ext This begins a 2-week poll on adopting this draft as a WG document. Please indicate your support/non-support for this document. Thanks, Deborah and Lou _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --=====003_Dragon344143370341_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PUdCMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjYwNTgiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQt ZmFtaWx5OiDLzszlOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFZlcmRhbmE7DQp9 DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQMvOzOU7DQp9DQpAcGFnZSBTZWN0aW9uMSB7 c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTog aW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsg Rk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpM SS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6 IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJ Rlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAw cHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0K fQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0N ClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRl cmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1ERUNPUkFUSU9OOiB1 bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBwdXJwbGU7 IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5bGUxNyB7DQoJRk9O VC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZTEU6IG5vcm1hbDsg Rk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsgbXNvLXN0eWxlLXR5 cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjEN Cn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KQkxPQ0tRVU9URSB7DQoJTUFSR0lO LVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHg7IE1BUkdJTi1MRUZUOiAyZW0NCn0NCk9MIHsN CglNQVJHSU4tVE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KVUwgew0KCU1BUkdJTi1U T1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4DQp9DQo8L1NUWUxFPg0KDQo8TUVUQSBjb250ZW50 PSJNU0hUTUwgNi4wMC4yOTAwLjIxODAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPkBmb250LWZh Y2Ugew0KCWZvbnQtZmFtaWx5OiDLzszlOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6 IFZlcmRhbmE7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQMvOzOU7DQp9DQpAcGFn ZSBTZWN0aW9uMSB7c2l6ZTogNTk1LjNwdCA4NDEuOXB0OyBtYXJnaW46IDcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDsgbGF5b3V0LWdyaWQ6IDE1LjZwdDsgfQ0KUC5Nc29Ob3JtYWwgew0KCVRF WFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBoOyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAw Y20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBq dXN0aWZ5DQp9DQpMSS5Nc29Ob3JtYWwgew0KCVRFWFQtSlVTVElGWTogaW50ZXItaWRlb2dyYXBo OyBGT05ULVNJWkU6IDEwLjVwdDsgTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6ICJU aW1lcyBOZXcgUm9tYW4iOyBURVhULUFMSUdOOiBqdXN0aWZ5DQp9DQpESVYuTXNvTm9ybWFsIHsN CglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJ TjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElH TjoganVzdGlmeQ0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1 bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNP UkFUSU9OOiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVYVC1E RUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNP TE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWlsU3R5 bGUxNyB7DQoJRk9OVC1XRUlHSFQ6IG5vcm1hbDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtU1RZ TEU6IG5vcm1hbDsgRk9OVC1GQU1JTFk6IFZlcmRhbmE7IFRFWFQtREVDT1JBVElPTjogbm9uZTsg bXNvLXN0eWxlLXR5cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFn ZTogU2VjdGlvbjENCn0NClVOS05PV04gew0KCUZPTlQtU0laRTogMTBwdA0KfQ0KPC9TVFlMRT4N CjwvSEVBRD4NCjxCT0RZIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IE1BUkdJTjogMTBweDsgRk9O VC1GQU1JTFk6IHZlcmRhbmEiPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjxGT05U IGZhY2U9VmVyZGFuYSBzaXplPTI+eWVzLCANCnN1cHBvcnQuPC9GT05UPjwvRk9OVD48L0RJVj4N CjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPllVTkJJTiBYVTwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6 ZT0yPltDQ0FNUF0gV0cgZG9jdW1lbnQgDQpwb2xsIGZvcmRyYWZ0LXpoYW5nLWNjYW1wLWdlbmVy YWwtY29uc3RyYWludHMtb3NwZi1leHQgPC9GT05UPjwvRElWPg0KPERJVj4NCjxESVY+PEZPTlQg ZmFjZT1WZXJkYW5hIHNpemU9Mj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFu YSBzaXplPTI+DQo8RElWPlRoaXMmbmJzcDtiZWdpbnMmbmJzcDthJm5ic3A7Mi13ZWVrJm5ic3A7 cG9sbCZuYnNwO29uJm5ic3A7YWRvcHRpbmcmbmJzcDt0aGlzJm5ic3A7ZHJhZnQmbmJzcDthcyZu YnNwO2EmbmJzcDtXRyZuYnNwO2RvY3VtZW50LjwvRElWPg0KPERJVj5QbGVhc2UmbmJzcDtpbmRp Y2F0ZSZuYnNwO3lvdXImbmJzcDtzdXBwb3J0L25vbi1zdXBwb3J0Jm5ic3A7Zm9yJm5ic3A7dGhp cyZuYnNwO2RvY3VtZW50LjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+VGhhbmtzLDwvRElWPg0K PERJVj5EZWJvcmFoJm5ic3A7YW5kJm5ic3A7TG91PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvRElWPg0KPERJ Vj5DQ0FNUCZuYnNwO21haWxpbmcmbmJzcDtsaXN0PC9ESVY+DQo8RElWPkNDQU1QQGlldGYub3Jn PC9ESVY+DQo8RElWPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8 L0RJVj48L0ZPTlQ+PC9ESVY+PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= --=====003_Dragon344143370341_=====-- From vijayc@hcl.com Mon Feb 28 22:34:12 2011 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 515093A6AA1 for ; Mon, 28 Feb 2011 22:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.905 X-Spam-Level: X-Spam-Status: No, score=-0.905 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSf0It7zGulZ for ; Mon, 28 Feb 2011 22:34:10 -0800 (PST) Received: from gws07.hcl.com (gws07.hcl.com [203.105.186.23]) by core3.amsl.com (Postfix) with ESMTP id 47A553A68B3 for ; Mon, 28 Feb 2011 22:34:09 -0800 (PST) Received: from chn-hclin-ht02.CORP.HCL.IN (10.249.64.36) by CHN-HCLIN-EDGE3.HCL.COM (10.249.64.140) with Microsoft SMTP Server id 8.2.254.0; Tue, 1 Mar 2011 12:04:06 +0530 Received: from CHN-HCLT-HT03.HCLT.CORP.HCL.IN (10.108.45.35) by chn-hclin-ht02.CORP.HCL.IN (10.249.64.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 1 Mar 2011 12:05:07 +0530 Received: from CHN-HCLT-EVS07.HCLT.CORP.HCL.IN ([fe80::f46b:fdf2:3218:985d]) by CHN-HCLT-HT03.HCLT.CORP.HCL.IN ([::1]) with mapi; Tue, 1 Mar 2011 12:05:07 +0530 From: "Vijayanand C - ERS, HCL Tech" To: Attila Takacs , "ccamp@ietf.org" Date: Tue, 1 Mar 2011 12:05:02 +0530 Thread-Topic: bidir LSP in rfc4803 Thread-Index: AcvXGXlU6/zpjV+LR4e5csqlwu092AAOKXfAACIC7+A= Message-ID: <66E3DDEEA70F0D469D1FFE238526B6ED3E446EF047@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> References: <66E3DDEEA70F0D469D1FFE238526B6ED3E446EE6D1@CHN-HCLT-EVS07.HCLT.CORP.HCL.IN> <6477E10CC7D76444A479B9AC31F262A9DD9D0C93@ESESSCMS0365.eemea.ericsson.se> In-Reply-To: <6477E10CC7D76444A479B9AC31F262A9DD9D0C93@ESESSCMS0365.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_66E3DDEEA70F0D469D1FFE238526B6ED3E446EF047CHNHCLTEVS07H_" MIME-Version: 1.0 Subject: Re: [CCAMP] bidir LSP in rfc4803 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 Mar 2011 06:34:12 -0000 --_000_66E3DDEEA70F0D469D1FFE238526B6ED3E446EF047CHNHCLTEVS07H_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attila, Thanks for the response. The draft which you mentioned also has a similar example with two cross con= nects with different mplsXCIndex and same mplsXCLSPID. One of the authors m= ailed today that it was a mistake and that it should really be the same mpl= sXCIndex . A related issue with this is , what will the XCPointer in the mplsTunnelTab= le ( of the MPLS-TE MIB) point to , if each tunnel entry has two correspond= ing cross entries. Regards Vijay From: Attila Takacs [mailto:Attila.Takacs@ericsson.com] Sent: Monday, February 28, 2011 8:19 PM To: Vijayanand C - ERS, HCL Tech; ccamp@ietf.org Subject: RE: bidir LSP in rfc4803 Hi Vijay, Thanks for pointing out the MIB aspects, this is indeed a bit lagging behin= d. However, initial work on TP specific MIB has been started recently: http://= tools.ietf.org/id/draft-vkst-mpls-tp-te-mib-00.txt discusses bidirectional = LSPs and I think the asymmetric bandwidth option should be addressed in tha= t document as it goes along. Attila ________________________________ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of V= ijayanand C - ERS, HCL Tech Sent: Monday, February 28, 2011 8:31 AM To: ccamp@ietf.org Subject: [CCAMP] bidir LSP in rfc4803 Hello All, How are the two directions of the cross connect of the bidirectional LSP co= rrelated It is not clear in RFC 4803. As per section 5, the cross connects will have the same XC index. " The GMPLS-LSR-STD-MIB module supports bidirectional LSPs as required for GMPLS. A single value of mplsXCIndex is shared by all of the segments for the entire bidirectional LSP. This facilitates a simple reference from [RFC3812] and [RFC480= 2] and makes fate-sharing more obvious. " But as per the example in section 6, the xcindex can be different but the m= plsXCLSPId must be same " In mplsXCTable: { mplsXCIndex =3D 0x01, mplsXCInSegmentIndex =3D 0x00000015, mplsXCOutSegmentIndex =3D 0x00000012, mplsXCLspId =3D 0x0102 -- unique ID mplsXCLabelStackIndex =3D 0x00, -- only a single outgoing label mplsXCRowStatus =3D createAndGo(4) } In mplsXCTable: { mplsXCIndex =3D 0x02, mplsXCInSegmentIndex =3D 0x00000016, mplsXCOutSegmentIndex =3D 0x00000013, mplsXCLspId =3D 0x0102 -- unique ID mplsXCLabelStackIndex =3D 0x00, -- only a single outgoing label mplsXCRowStatus =3D createAndGo(4) } " Will the mplsXCindex be same or different, please clarify. Regards Vijay ________________________________ ::DISCLAIMER:: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliate= s. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect t= he opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have received this email in error please delete it and notify the sender immedia= tely. Before opening any mail and attachments please check them for viruses and defect. ---------------------------------------------------------------------------= -------------------------------------------- --_000_66E3DDEEA70F0D469D1FFE238526B6ED3E446EF047CHNHCLTEVS07H_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Attila,

Thanks for the response.=

 =

The draft which you ment= ioned also has a similar example with two cross connects with different mplsXCInd= ex and same mplsXCLSPID. One of the authors mailed today that it was a mistake= and that it should really be the same mplsXCIndex .

 =

A related issue with thi= s is , what will the XCPointer in the mplsTunnelTable ( of the MPLS-TE MIB) point = to , if each tunnel entry has two corresponding cross entries.

 =

Regards

Vijay=

From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]
Sent: Monday, February 28, 2011 8:19 PM
To: Vijayanand C - ERS, HCL Tech; ccamp@ietf.org
Subject: RE: bidir LSP in rfc4803

 

Hi Vijay,

 

Thanks for pointing out the MIB aspects, this is indeed a bit lagging behind.

 

However, initial work on TP specific MIB ha= s been started recently: http://t= ools.ietf.org/id/draft-vkst-mpls-tp-te-mib-00.txt discusses bidirectional LSPs and I think the asymmetric bandwidth option should be addressed in that document as it goes along.

 

Attila

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Vijayanand C - ERS, HCL Tech
Sent: Monday, February 28, 2011 8:31 AM
To: ccamp@ietf.org
Subject: [CCAMP] bidir LSP in rfc4803

Hello All,

 

How are the two directions of the cross connect of the bidirec= tional LSP correlated

It is not clear in RFC 4803.

 

As per section 5, the cross connects will have the same XC ind= ex.

"

The GMPLS-LSR-STD-MIB module supports bidirectional LSPs as required
   for GMPLS.  A single value of mplsXCIndex is shared by all of the
   segments= for the entire bidirectional LSP.  This facilitates a simple    referenc= e from [RFC3812] and [RFC4802] and makes fate-sharing more
   obvious.=
"

 

But as per the example in section 6, the xcindex can be differ= ent but the mplsXCLSPId must be same

 

" In mplsXCTable:
   {=
   &nb= sp;  mplsXCIndex          &nbs= p;     =3D 0x01,
   &nb= sp;  mplsXCInSegmentIndex       =3D 0x00000015,
   &nb= sp;  mplsXCOutSegmentIndex      =3D 0x00000012,<= /em>
   &nb= sp;  mplsXCLspId          &nbs= p;     =3D 0x0102 -- unique ID
   &nb= sp;  mplsXCLabelStackIndex      =3D 0x00, -- only a sin= gle outgoing label
   &nb= sp;  mplsXCRowStatus          =   =3D createAndGo(4)
   }=

   In mplsXCTable:
   {=
   &nb= sp;  mplsXCIndex          &nbs= p;     =3D 0x02,
   &nb= sp;  mplsXCInSegmentIndex       =3D 0x00000016,
   &nb= sp;  mplsXCOutSegmentIndex      =3D 0x00000013,<= /em>
   &nb= sp;  mplsXCLspId          &nbs= p;     =3D 0x0102 -- unique ID
   &nb= sp;  mplsXCLabelStackIndex      =3D 0x00, -- only a sin= gle outgoing label
   &nb= sp;  mplsXCRowStatus          =   =3D createAndGo(4)
   }=
"

 

 

Will the mplsXCindex be same or different, please clarify.

 

 

Regards

Vijay

 

::DISCLAIMER::
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and inte= nded for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliate= s. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect t= he opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.

---------------------------------------------------------------------------= --------------------------------------------

--_000_66E3DDEEA70F0D469D1FFE238526B6ED3E446EF047CHNHCLTEVS07H_-- From huawei.danli@huawei.com Mon Feb 28 23:57:05 2011 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 359973A6A97 for ; Mon, 28 Feb 2011 23:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=2.748, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, 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 cwqQjjQvmDCa for ; Mon, 28 Feb 2011 23:57:03 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 970EE3A6A08 for ; Mon, 28 Feb 2011 23:56:58 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHD00AW2COVIV@szxga03-in.huawei.com> for ccamp@ietf.org; Tue, 01 Mar 2011 15:55:43 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHD00EY2COLIL@szxga03-in.huawei.com> for ccamp@ietf.org; Tue, 01 Mar 2011 15:55:43 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 01 Mar 2011 15:55:20 +0800 Received: from l00037133 (10.70.77.125) by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 01 Mar 2011 15:55:25 +0800 Date: Tue, 01 Mar 2011 15:55:25 +0800 From: Dan Li X-Originating-IP: [10.70.77.125] To: "BRUNGARD, DEBORAH A (ATTSI)" , CCAMP Message-id: <00cf01cbd7e6$05ea6b50$7d4d460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Subject: Re: [CCAMP] WG document poll fordraft-zhang-ccamp-general-constraints-ospf-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: Tue, 01 Mar 2011 07:57:05 -0000 Yes, support! Dan ----- Original Message ----- From: "BRUNGARD, DEBORAH A (ATTSI)" To: "CCAMP" Sent: Tuesday, February 22, 2011 1:09 AM Subject: [CCAMP] WG document poll fordraft-zhang-ccamp-general-constraints-ospf-ext > This begins a 2-week poll on adopting this draft as a WG document. > Please indicate your support/non-support for this document. > > Thanks, > Deborah and Lou > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp