From leeyoung@huawei.com Fri Oct 7 14:23:46 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F8221F8BC4 for ; Fri, 7 Oct 2011 14:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSfDNiUgPvPb for ; Fri, 7 Oct 2011 14:23:45 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 65A3221F8B85 for ; Fri, 7 Oct 2011 14:23:45 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSP00KQ6SWXO2@usaga02-in.huawei.com> for rtg-dir@ietf.org; Fri, 07 Oct 2011 16:26:58 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LSP00GJ0SWX9K@usaga02-in.huawei.com> for rtg-dir@ietf.org; Fri, 07 Oct 2011 16:26:57 -0500 (CDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 07 Oct 2011 14:26:50 -0700 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Fri, 07 Oct 2011 14:26:48 -0700 Date: Fri, 07 Oct 2011 21:26:48 +0000 From: Leeyoung X-Originating-IP: [10.47.145.96] To: "rtg-ads@tools.ietf.org" Message-id: <7AEB3D6833318045B4AE71C2C87E8E171817F447@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tXMVwi30F0F02JUwJr7Zbg)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: RtgDir review: draft-ietf-ccamp-attribute-bnf-02.txt Thread-index: AcyFN9I6RzuixG9cRq+U3ev6WtQUxw== X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: "draft-ietf-ccamp-attribute-bnf.all@tools.ietf.org" , "rtg-dir@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-ccamp-attribute-bnf-02.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 21:23:46 -0000 --Boundary_(ID_tXMVwi30F0F02JUwJr7Zbg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ccamp-attribute-bnf-02.txt Reviewer: Young Lee Review Date: 7 October 2011 IETF LC End Date: 10 October 2011 Intended Status: Standard track Summary: I have no major concerns about this document that I think should be resolved before publication. Comments: This document is clearly written and easy to understand. Major Issues: No major issues found. Minor Issues: Section 3.2.1 I am not sure if I understand this compatibility section written as follows: A node that does not support the LSP Attribute object formatting as defined in this section will interpret the first present LSP Attribute object as representing LSP operational status even when it is intended to represent S2L sub-LSP status. It is unclear if this is a significant issue as the LSP Attribute object is currently considered to be an unsuitable mechanism for reporting operational status of P2MP LSPs, for example see Section 2.1 of [NO-PHP-OOB]. The intent of this document is to correct this limitation and it is expected that networks that wish to make use of such operational reporting will deploy this extension. If the node that does not support this new LSP attribute object, how can it interprets the first Present LSP Attribute object as LSP operational status if the LSP attribute object is not a suitable mechanism currently for reporting operational status of P2MP LSPs? It sounds like a contradictory statement as I read. Please clarify this section if needed. Nits: None identified --Boundary_(ID_tXMVwi30F0F02JUwJr7Zbg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-ccamp-attribute-bnf-02.txt

Reviewer: Young Lee
Review Date: 7 October 2011
IETF LC End Date: 10 October 2011
Intended Status: Standard track

Summary:
I have no major concerns about this document that I think should be resolved before publication.

Comments:
This document is clearly written and easy to understand.

Major Issues:
No major issues found. 

Minor Issues: 
Section 3.2.1 
 
I am not sure if I understand this compatibility section written as follows: 
 
     A node that does not support the LSP Attribute object formatting as

   defined in this section will interpret the first present LSP

   Attribute object as representing LSP operational status even when it

   is intended to represent S2L sub-LSP status.  It is unclear if this

   is a significant issue as the LSP Attribute object is currently

   considered to be an unsuitable mechanism for reporting operational

   status of P2MP LSPs, for example see Section 2.1 of [NO-PHP-OOB].

   The intent of this document is to correct this limitation and it is

   expected that networks that wish to make use of such operational

   reporting will deploy this extension.

 

If the node that does not support this new LSP attribute object, how can it interprets the first

Present LSP Attribute object as LSP operational status if the LSP attribute object is not a suitable

mechanism currently for reporting operational status of P2MP LSPs?

 

It sounds like a contradictory statement as I read. Please clarify this section if needed.

 

 

 

Nits:
None identified

 

--Boundary_(ID_tXMVwi30F0F02JUwJr7Zbg)-- From lberger@labn.net Mon Oct 10 06:20:06 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A26F21F8BD3 for ; Mon, 10 Oct 2011 06:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.861 X-Spam-Level: X-Spam-Status: No, score=-98.861 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXscSVKfHeT9 for ; Mon, 10 Oct 2011 06:20:05 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 49BE421F8BB9 for ; Mon, 10 Oct 2011 06:20:05 -0700 (PDT) Received: (qmail 25008 invoked by uid 0); 10 Oct 2011 13:20:02 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 10 Oct 2011 13:20:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=N2XchwF05+OtXf7STTQ064ZWhcqDCvUbsEYFfqPbS3c=; b=KCxMuivCl4cWBlwMuPgpS6T0BoO1l4syFchF7/M3aMUE96L/qGSNY2VmsC92MfqHNZRIVq62fazqRsPXJd3EX3tSQLnzYfrSH1rpoAx4Y107PpAPWl073ZXZHPaqIFik; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RDFly-0007fw-4D; Mon, 10 Oct 2011 07:20:02 -0600 Message-ID: <4E92F104.6050808@labn.net> Date: Mon, 10 Oct 2011 09:20:04 -0400 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: Leeyoung References: <7AEB3D6833318045B4AE71C2C87E8E171817F447@DFWEML501-MBX.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E171817F447@DFWEML501-MBX.china.huawei.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-attribute-bnf.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-attribute-bnf-02.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 13:20:06 -0000 Young, Thank you for the comments. Please see below for in-line responses. Lou On 10/7/2011 5:26 PM, Leeyoung wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review. The purpose > of the review is to provide assistance to the Routing ADs. For more > information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-ccamp-attribute-bnf-02.txt > > Reviewer: Young Lee > Review Date: 7 October 2011 > IETF LC End Date: 10 October 2011 > Intended Status: Standard track > > *Summary:* > I have no major concerns about this document that I think should be > resolved before publication. > > *Comments:* > This document is clearly written and easy to understand. > > *Major Issues:* > No major issues found. > > *Minor Issues:* > Section 3.2.1 > > > I am not sure if I understand this compatibility section written as follows: > > A node that does not support the LSP Attribute object formatting as > defined in this section will interpret the first present LSP > Attribute object as representing LSP operational status even when it > is intended to represent S2L sub-LSP status. It is unclear if this > is a significant issue as the LSP Attribute object is currently > considered to be an unsuitable mechanism for reporting operational > status of P2MP LSPs, for example see Section 2.1 of [NO-PHP-OOB]. > The intent of this document is to correct this limitation and it is > expected that networks that wish to make use of such operational > reporting will deploy this extension. > > If the node that does not support this new LSP attribute object, how can > it interprets the first > Present LSP Attribute object as LSP operational status if the LSP > attribute object is not a suitable > mechanism currently for reporting operational status of P2MP LSPs? > > It sounds like a contradictory statement as I read. Please clarify this > section if needed. Does the following revision clarify the paragraph? OLD: > A node that does not support the LSP Attribute object formatting as > defined in this section will interpret the first present LSP > Attribute object as representing LSP operational status even when it > is intended to represent S2L sub-LSP status. NEW: A node that supports [RFC4875] and [RFC5420], but not this document, will interpret the first LSP Attribute object present in a received message, which is formatted as described in this document, as representing LSP operational status rather than S2L sub-LSP status. Lou > > > *Nits:* > None identified > > > From acee.lindem@ericsson.com Mon Oct 10 10:16:19 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5954221F8C3A for ; Mon, 10 Oct 2011 10:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYZrQklYr25C for ; Mon, 10 Oct 2011 10:16:17 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD7F21F87E2 for ; Mon, 10 Oct 2011 10:16:17 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9AHFVti004559; Mon, 10 Oct 2011 12:15:39 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 10 Oct 2011 13:15:34 -0400 From: Acee Lindem To: Greg Bernstein , Dan Li , Young Lee , Giovanni Martinelli Date: Mon, 10 Oct 2011 13:15:33 -0400 Thread-Topic: Routing-Directory Review of "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments" - draft-ietf-ccamp-wson-impairments-07.txt Thread-Index: AcyHcDhDr14yzGLLTbmWYTQof9WvVg== Message-ID: <486FA0F6-EE68-4AAA-AA12-58F43B1F6903@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "ccamp-chairs@tools.ietf.org" , Adrian Farrel Subject: [RTG-DIR] Routing-Directory Review of "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments" - draft-ietf-ccamp-wson-impairments-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 17:16:19 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t the Routing Directorate, please see http://www.ietf.org/iesg/directorate/= routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-ccamp-wson-impairments-07.txt Reviewer: Acee Lindem Review Date: 2011-10-10 IETF LC End Date: TBD Intended Status: Informational Summary: I have no major concerns about this document that I think must be resolved before publication. I have some suggestions below. Major Issues: No major issues found. Minor Issues: The document is somewhat hard to read and I've included some editorial sugg= estions below. Some of tthese are subjective and style based. For example, = I prefer a comma after a prepositional phase preceding an independent claus= e. Other suggested edits are obvious typos (so you'll need to look at them = all ;^). Additionally, I'd suggest the following: Abstract: Mention the components included in the framework in the abstrac= t and introduction to set the context for the remainder of the document. 2 - Include "black link". 4.1.1, Scenario D - The detailed case is designated as out of scope yet i= t is referred to in later sections. For example, section 4.3. 4.1.3 - What is the Q factor? 4.2 - Explain what you mean by "at-most K paths". Define K. 4.2 - Why is there assumed to be one IV process and multiple RWA processe= s? General: Would it make sense to include a discussion of the order in whic= h PCE, WA, and IV should be done to avoid redundant computation? Editorial Comments: Missing acronyms expansions: ADM, NEs, OSNR, DGD, PXCs, and OADMs Acee-Lindems-MacBook-Pro:Desktop ealflin$ diff draft-ietf-ccamp-wson-impair= ments-07.txt.orig draft-ietf-ccamp-wson-impairments-07.txt 136c136 < As an optical signal progresses along its path it may be altered by --- > As an optical signal progresses along its path, it may be altered by 142c142 < used, the types and placement of various optical devices and the --- > used, the types and placement of various optical devices, and the 149c149 < a WSON, a combination of path continuity, resource availability and --- > a WSON, a combination of path continuity, resource availability, and 157c157 < that use time division multiplexing, and WDM. The Path Computation --- > that use time division multiplexing and WDM. The Path Computation 189c189 < CWDM: Coarse Wavelength Division Multiplexing. --- > CWDM: Coarse Wavelength Division Multiplexing 191c191 < DWDM: Dense Wavelength Division Multiplexing. --- > DWDM: Dense Wavelength Division Multiplexing 193c193 < FOADM: Fixed Optical Add/Drop Multiplexer. --- > FOADM: Fixed Optical Add/Drop Multiplexer 195c195 < GMPLS: Generalized Multi-Protocol Label Switching. --- > GMPLS: Generalized Multi-Protocol Label Switching 204c204 < OXC: Optical cross connect. An optical switching element in which a --- > OXC: Optical cross connect - An optical switching element in which a 207c207 < PCC: Path Computation Client. Any client application requesting a --- > PCC: Path Computation Client - Any client application requesting a 210c210 < PCE: Path Computation Element. An entity (component, application, or --- > PCE: Path Computation Element - An entity (component, application, or 219c219 < PCEP: PCE Communication Protocol. The communication protocol between --- > PCEP: PCE Communication Protocol - The communication protocol between 222c222 < ROADM: Reconfigurable Optical Add/Drop Multiplexer. A wavelength --- > ROADM: Reconfigurable Optical Add/Drop Multiplexer - A wavelength 226c226 < RWA: Routing and Wavelength Assignment. --- > RWA: Routing and Wavelength Assignment 247c247 < WDM: Wavelength Division Multiplexing. --- > WDM: Wavelength Division Multiplexing 281c281 < cross connects to increase network flexibility. In such cases --- > cross connects to increase network flexibility. In such cases, 335,336c335,336 < contains transparent elements and electro-optical elements such as < OEO regenerations. In such networks a generic light path can go --- > contain transparent elements and electro-optical elements such as > OEO regenerations. In such networks, a generic light path can go 341,342c341,342 < (i) wavelength conversion to assist RWA to avoid wavelength blocking. < This is the impairment free case covered by [RFC6163]. --- > (i) Due to wavelength conversion to assist RWA to avoid wavelength > blocking. This is the impairment free case covered by [RFC6163]. 344,345c344,345 < (ii) the optical signal without regeneration would be too degraded < to meet end to end BER requirements. This is the case when RWA --- > (ii) The optical signal without regeneration would be too degraded > to meet end-to-end BER requirements. This is the case when RWA 349c349 < In the latter case an optical path can be seen as a set of transparent --- > In the latter case, an optical path can be seen as a set of transparent 371,372c371,372 < constraints that an impairment aware optical control plane may have < to operate under. These requirements and constraints motivate the IA- --- > constraints under which an impairment aware optical control plane may = have > to operate. These requirements and constraints motivate the IA- 396,397c396,397 < In this case impairments are only taken into account during network < design and after that, for example during optical path computation, --- > In this case, impairments are only taken into account during network > design. After that, for example during optical path computation, 452c452 < channel interfaces to multi-channel DWDM systems only the single --- > channel interfaces to multi-channel DWDM systems, only the single 456c456 < available. Note however the overall impact of a black link at the --- > available. However, note that the overall impact of a black link at th= e 461c461 < spans and to estimate the validity of optical paths. For example, --- > spans in order to estimate the validity of optical paths. For example, 468c468 < for optical networks with "black links" (path) could not be performed --- > for optical networks with "black links" in the path could not be perfo= rmed 473c473 < entity. Such a vendor specific IA computation, could utilize --- > entity. Such a vendor specific IA computation could utilize 477c477 < In the following the term "black links" will be used to describe --- > In the following, the term "black links" will be used to describe 479c479 < networks. From the control plane perspective the following options --- > networks. From the control plane perspective, the following options 493,495c493,495 < computation entity. The difficulty here is for larger networks < such a list of paths along with any wavelength constraints could < get unmanageably large. --- > computation entity. The difficulty here is that such a list of > paths along with any wavelength constraints could get unmanageably > large as the size of the network increases. 497,498c497,498 < 2. The authority in control of the "black links" could provide a PCE < like entity a list of viable paths/wavelengths between two --- > 2. The authority in control of the "black links" could provide a > PCE-like entity that returns a list of viable paths/wavelengths bet= ween two 500,501c500,501 < and can reduce the scaling issue previously mentioned. Such a PCE < like entity would not need to perform a full RWA computation, --- > and can reduce the scaling issue previously mentioned. Such a PCE-l= ike > entity would not need to perform a full RWA computation, 563c563 < Starting from functional block on the left the Optical Interface --- > Starting from functional block on the left, the Optical Interface 565,567c565,567 < defines the properties at the path end points. Even the no-impairment < case like scenario B in section 4.1.1 needs to consider a minimum set < of interface characteristics. In such case only a few parameters used --- > defines the properties at the path end-points. Even the impairment-fre= e > case, like scenario B in section 4.1.1, needs to consider a minimum se= t > of interface characteristics. In such case, only a few parameters used 569,570c569,570 < [RFC6163]). For the impairment-aware case these parameters may be < sufficient or not depending on the accepted level of approximation --- > [RFC6163]). For the impairment-aware case, these parameters may or may > not be sufficient depending on the accepted level of approximation 572c572 < consider a set of interface parameters during an Impairment --- > consider a set of interface parameters during the Impairment 580,582c580,582 < Options for this will be given in the next section on architectural < alternatives. This block implementation (e.g. through routing, < signaling or PCE) may influence the way the control plane distributes --- > Architectural alternatives to acommplish this are provided in > section 4.2. This block implementation (e.g., through routing, > signaling, or PCE) may influence the way the control plane distributes 586,587c586,587 < Depending on the IA level of approximation this function can be more < or less complex. For example in case of no IA only the signal class --- > Depending on the IA level of approximation, this function can be more > or less complex. For example, in the case of no IA, only the signal cl= ass 599c599 < taken in the physical modeling (worst-case, statistical or based on --- > taken in the physical modeling (worst-case, statistical, or based on 602,603c602,603 < marking some paths as not-feasible while they are very likely to be < feasible in reality. --- > marking some paths as not-feasible which are very likely to be, in > reality, feasible. 609c609 < From a control plane point of view optical impairments are additional --- > From a control plane point of view, optical impairments are additional 614c614 < Validation (estimation) (IV). --- > Validation (IV), i.e., estimation. 618c618 < point of view the following three forms of impairment validation will --- > point of view, the following three forms of impairment validation will 623c623 < In this case an Impairment Validation (IV) process furnishes a set of --- > In this case, an Impairment Validation (IV) process furnishes a set of 630c630 < discloses optical impairment information. Note that that this case --- > discloses optical impairment information. Note that this case 634c634 < In this case the control plane simply makes use of candidate paths --- > In this case, the control plane simply makes use of candidate paths 636c636 < is when the path validity is assessed within the control plane. The --- > is to assess the path validity within the control plane. The 656c656 < In this case an IV process is given a particular path and wavelength --- > In this case, an IV process is given a particular path and wavelength 667c667 < In this case impairments to a path are computed at a single entity. --- > In this case, impairments to a path are computed at a single entity. 669c669 < gathered from network elements. Depending how information is gathered --- > gathered from network elements. Depending how information is gathered, 676c676 < as OSNR, dispersion, DGD, etc. may be accumulated along the path via --- > as OSNR, dispersion, DGD, etc., may be accumulated along the path via 679c679 < measures reach the destination node a decision on the impairment --- > measures reach the destination node, a decision on the impairment 685,686c685,686 < The Control Plane must not preclude the possibility to operate one or < all the above cases concurrently in the same network. For example --- > The Control Plane must not preclude the possibility to concurrently > perform one or all the above cases in the same network. For example, 690c690 < same network however the control plane may compute a path outside the --- > same network, however, the control plane may compute a path outside th= e 695c695 < computation architectures and reviews some of their respective --- > computation architectures and review some of their respective 708c708 < solutions can be achieved if the path computation entity (PCE) can --- > solutions can be achieved if the Path Computation Entity (PCE) can 710c710 < wavelength assignment and impairment validation. --- > wavelength assignment, and impairment validation. 718c718 < Separating the processes of routing, WA and/or IV can reduce the need --- > Separating the processes of routing, WA, and/or IV can reduce the need 721c721 < [RFC6163]. In addition, as was discussed some impairment information --- > [RFC6163]. In addition, as was discussed, some impairment information 724c724 < precision it may be advantageous to offload this computation to a --- > precision, it may be advantageous to offload this computation to a 735c735 < validation is typically wavelength dependent hence combining WA --- > validation is typically wavelength dependent. Hence, combining WA 743c743 < selected path and wavelength. If IV comes first it would need to --- > selected path and wavelength. If IV comes first, it would need to 749,751c749,751 < In the non-impairment RWA situation [RFC6163] it was shown that a < distributed wavelength assignment (WA) process carried out via < signaling can eliminate the need to distribute wavelength --- > In the non-impairment RWA situation [RFC6163], it was shown that a > distributed wavelength assignment (WA) process, carried out via > signaling, can eliminate the need to distribute wavelength 761,762c761,762 < characteristics of network elements and links via routing protocols < or by other means. So the following conceptual options belong to this --- > characteristics of network elements and links by routing protocols > or other means. So the following conceptual options belong to this 779,781c779,782 < all wavelengths that could be used. This is somewhat windowed down as < potential wavelengths are discovered to be in use, but could be a < significant burden for lightly loaded high channel count networks. --- > all wavelengths that could be used. The amount of information is redun= ced > somewhat as potential wavelengths are discovered to be in use, but cou= ld > be a significant burden for lightly loaded network with high channel > counts. 785c786 < Figure 2 shows process flows for three main architectural --- > Figure 2 shows process flows for the three main architectural 787c788 < sufficient. Figure 3 shows process flows for two main architectural --- > sufficient. Figure 3 shows process flows for the two main architectura= l 841c842 < The advantages, requirements and suitability of these options are as --- > The advantages, requirements, and suitability of these options are as 847c848 < entity enabling highest potential optimality and efficiency in IA- --- > entity enabling the highest potential optimality and efficiency in IA- 870c871 < and RWA are very different and prone to specialization. --- > and RWA are very different and conducive to specialization. 874c875 < In this alternative a signaling protocol may be extended and --- > In this alternative, a signaling protocol may be extended and 877c878 < optimality of optimality as (a) or (b), it does not require --- > optimality as (a) or (b), it does not require 903c904 < The advantages, requirements and suitability of these detailed --- > The advantages, requirements, and suitability of these detailed 909,911c910,912 < computation entity enabling highest potential optimality and < efficiency in IA-RWA; then has a separate entity performing detailed < impairment validation. In the case of "black links" the authority --- > computation entity enabling the highest potential optimality and > efficiency in IA-RWA while a separate entity performs detailed > impairment validation. In the case of "black links", the authority 925c926 < high degree of potential optimality and efficiency in IA-RWA; then a --- > high degree of potential optimality and efficiency in IA-RWA while a 963,966c964,967 < As previously discussed most IA-RWA scenarios to a greater or lesser < extent rely on a common impairment information model. A number of < ITU-T recommendations cover detailed as well as approximate < impairment characteristics of fibers and a variety of devices and --- > As previously discussed, most IA-RWA scenarios rely, to a greater or l= esser > extent, on a common impairment information model. A number of > ITU-T recommendations cover detailed, as well as, approximate > impairment characteristics of fibers, a variety of devices, and 979,980c980,981 < the networks composed of a single WDM line system vendor combined < with OADMs and/or PXCs from potentially multiple other vendors, this --- > networks composed of a single WDM line system vendor combined > with OADMs and/or PXCs from potentially multiple other vendors. This 982,984c983,985 < planed in the future that [G.680] will include networks incorporating < line systems from multiple vendors as well as OADMs and/or PXCs from < potentially multiple other vendors, this is known as situation 2 and --- > planned in the future that [G.680] will include networks incorporating > line systems from multiple vendors, as well as, OADMs and/or PXCs kfro= m > potentially from multiple other vendors. This is known as situation 2 = and 990c991 < distributed IV case one needs to standardize the accumulated --- > distributed IV case, one needs to standardize the accumulated 996c997 < and in what form for the protocol would need to be standardized for --- > and in what form would need to be standardized for protocol 1005c1006 < Different approaches to path/wavelength impairment validation gives --- > Different approaches to path/wavelength impairment validation give 1008c1009 < paths GMPLS routing may be used to distribute the impairment --- > paths, GMPLS routing may be used to distribute the impairment 1012,1013c1013,1014 < Depending on the computational alternative the routing protocol may < need to advertise information necessary to impairment validation --- > Depending on the computational alternative, the routing protocol may > need to advertise information necessary to the impairment validation 1015,1018c1016,1019 < high amount of data that need to be advertised. Such issue can be < addressed separating data that need to be advertised rarely and data < that need to be advertised more frequently or adopting other form of < awareness solutions described in previous sections (e.g. centralized --- > volume of data that needs to be advertised. Such issue can be > addressed by separating data that need to be advertised rarely from da= ta > that need to be advertised more frequently or adopting the other forms= of > awareness solutions as described in previous sections (e.g., centraliz= ed 1029,1030c1030,1031 < In term of approximated scenario (see Section 4.1.1.) the model < defined by [G.680] will apply and routing protocol will need to --- > In term of approximated scenario (see Section 4.1.1.), the model > defined by [G.680] will apply and the routing protocols will need to 1033c1034 < In the case of distributed-IV no new demands would be placed on the --- > In the case of distributed-IV, no new demands would be placed on the 1054c1055 < In section 4.3. a number of computation architectural alternatives --- > In section 4.3, a number of computation architectural alternatives 1058,1059c1059,1060 < cooperating PCEs, and the impacts on the PCEP protocol. This document < is providing this evaluation to aid solutions work. The protocol --- > cooperating PCEs, and the impacts on the PCEP. This document > provide this evaluation to aid solutions work. The protocol 1085c1086 < wavelength. If the computations could not complete successfully it --- > wavelength. If the computations could not complete successfully, it 1087,1088c1088,1089 < it is of interest to know if this was due to lack of wavelength < availability or impairment considerations or both. The information --- > it is of interest to know if failure was due to lack of wavelength > availability, impairment considerations, or both. The information 1098c1099 < functionality can be added to one of previously defined entities. --- > functionality could be added to one of previously defined entities. 1100c1101 < process coordinator. The roles, responsibilities and information --- > process coordinator. The roles, responsibilities, and information 1107,1108c1108,1109 < as needed during RWA computations. In particular it needs to know to < use the Candidates-PCE to obtain potential set of routes and --- > as needed during RWA computations. In particular, it needs to know to > use the Candidates-PCE to obtain the potential set of routes and 1130c1131 < computation. It needs not take into account current link wavelength --- > computation. It need not take into account current link wavelength 1139,1140c1140,1141 < initiating PCC. (Note: RWA-Coord PCE is also a PCC with respect to < the IV-Candidate) --- > initiating PCC. Note that the RWA-Coord PCE is also a PCC with respect= to > the IV-Candidate. 1174c1175 < Coordinating-PCE and the IV-Candidates-PCE. --- > Coordinating-PCE, and the IV-Candidates-PCE. 1176c1177 < In step (a) the PCC requests a path meeting specified quality --- > In step (a), the PCC requests a path meeting specified quality 1179,1181c1180,1182 < associated parameters. In step (b) the RWA-Coordinating-PCE requests < up to K candidate paths between nodes A and Z and associated < acceptable wavelengths. In step (c) The IV-Candidates PCE returns --- > associated parameters. In step (b), the RWA-Coordinating-PCE requests > up to K candidate paths and their associated acceptable wavelengths > between nodes A and Z . In step (c), the IV-Candidates PCE returns 1183c1184 < paths and wavelengths as input (e.g. a constraint) to its RWA --- > paths and wavelengths as input (e.g., a constraint) to its RWA 1191c1192 < computation. In step (d) the RWA-Coordinating PCE returns the overall --- > computation. In step (d), the RWA-Coordinating PCE returns the overall 1196c1197 < Previously Figure 3 showed two cases where a separate detailed --- > Previously, Figure 3 showed two cases where a separate detailed 1200c1201 < the PCC it is possible to keep the interactions with this separate --- > the PCC, it is possible to keep the interactions with this separate 1211c1212 < will furnish signal characteristics, quality requirements, path --- > will furnish signal characteristics, quality requirements, path, 1216c1217 < actually be met. In the case where the impairment validation fails --- > actually be met. In the case where the impairment validation fails, 1218c1219 < quantify the failure, e.g., so a judgment can be made whether to --- > quantify the failure, e.g., so that a judgment can be made whether = to 1221c1222 < Figure 6 shows a sequence diagram for the interactions for the --- > Figure 6 shows a sequence diagram for the interactions corresponding t= o the 1223c1224 < PCC, RWA-PCE (acting as coordinator), IV-Candidates-PCE and the IV- --- > PCC, RWA-PCE (acting as coordinator), IV-Candidates-PCE, and the IV- 1226c1227 < In step (a) the PCC requests a path meeting specified quality --- > In step (a), the PCC requests a path meeting specified quality 1229,1231c1230,1232 < associated parameters. In step (b) the RWA-Coordinating-PCE requests < up to K candidate paths between nodes A and Z and associated < acceptable wavelengths. In step (c) The IV-Candidates-PCE returns --- > associated parameters. In step (b), the RWA-Coordinating-PCE requests > up to K candidate paths and their associated acceptable wavelengths > between nodes A and Z. In step (c), the IV-Candidates-PCE returns 1233,1234c1234,1235 < paths and wavelengths as input (e.g. a constraint) to its RWA < computation. In step (d) the RWA-Coordinating-PCE request a detailed --- > paths and wavelengths as input (e.g., a constraint) to its RWA > computation. In step (d), the RWA-Coordinating-PCE requests a detailed 1236,1237c1237,1238 < (e) the IV-Detailed-PCE returns the results of the validation to the < RWA-Coordinating-PCE. Finally in step (f)IA-RWA-Coordinating PCE --- > (e), the IV-Detailed-PCE returns the results of this validation to the > RWA-Coordinating-PCE. Finally in step (f), the IA-RWA-Coordinating PCE 1277c1278 < Coordinating-PCE, IV-Candidates-PCE and IV-Detailed-PCE. --- > Coordinating-PCE, IV-Candidates-PCE, and IV-Detailed-PCE. 1285c1286 < architecture is put into use within a network it will by its nature --- > architecture is put into use within a network, it will by its nature 1290c1291 < work will address any issues on the use of impairment information. --- > work will address any issues on the protection of impairment informati= on. Thanks, Acee From adrian@olddog.co.uk Mon Oct 10 10:30:42 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3C321F863E for ; Mon, 10 Oct 2011 10:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=0.897, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pkUAHuqLraE for ; Mon, 10 Oct 2011 10:30:40 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 642B721F85F7 for ; Mon, 10 Oct 2011 10:30:39 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p9AHUMkB025441; Mon, 10 Oct 2011 18:30:22 +0100 Received: from 950129200 (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p9AHUIIA025431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Oct 2011 18:30:19 +0100 From: "Adrian Farrel" To: "'Acee Lindem'" , "'Greg Bernstein'" , "'Dan Li'" , "'Young Lee'" , "'Giovanni Martinelli'" References: <486FA0F6-EE68-4AAA-AA12-58F43B1F6903@ericsson.com> In-Reply-To: <486FA0F6-EE68-4AAA-AA12-58F43B1F6903@ericsson.com> Date: Mon, 10 Oct 2011 18:30:16 +0100 Message-ID: <01a001cc8772$47cb2960$d7617c20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKF01E3enhxGgor0ZNGNNFwrKH2yJQDPTxw Content-Language: en-gb Cc: rtg-dir@ietf.org, ccamp-chairs@tools.ietf.org Subject: Re: [RTG-DIR] Routing-Directory Review of "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments" - draft-ietf-ccamp-wson-impairments-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 17:30:42 -0000 Acee, thanks. Authors, I think there are enough small edits here that you will want to make a revision. Thanks, Adrian > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com] > Sent: 10 October 2011 18:16 > To: Greg Bernstein; Dan Li; Young Lee; Giovanni Martinelli > Cc: rtg-dir@ietf.org; ccamp-chairs@tools.ietf.org; Adrian Farrel > Subject: Routing-Directory Review of "A Framework for the Control of > Wavelength Switched Optical Networks (WSON) with Impairments" - draft-ietf- > ccamp-wson-impairments-07.txt > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. The > Routing Directorate seeks to review all routing or routing-related drafts as they > pass through IETF last call and IESG review. The purpose of the review is to > provide assistance to the Routing ADs. For more information about the Routing > Directorate, please see http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it would > be helpful if you could consider them along with any other IETF Last Call > comments that you receive, and strive to resolve them through discussion or by > updating the draft. > > > Document: draft-ietf-ccamp-wson-impairments-07.txt > Reviewer: Acee Lindem > Review Date: 2011-10-10 > IETF LC End Date: TBD > Intended Status: Informational > > Summary: > I have no major concerns about this document that I think must be > resolved before publication. I have some suggestions below. > > Major Issues: > No major issues found. > > Minor Issues: > The document is somewhat hard to read and I've included some editorial > suggestions below. Some of tthese are subjective and style based. For example, I > prefer a comma after a prepositional phase preceding an independent clause. > Other suggested edits are obvious typos (so you'll need to look at them all ;^). > > Additionally, I'd suggest the following: > > Abstract: Mention the components included in the framework in the abstract > and introduction > to set the context for the remainder of the document. > > 2 - Include "black link". > > 4.1.1, Scenario D - The detailed case is designated as out of scope yet it is > referred to > in later sections. For example, section 4.3. > > 4.1.3 - What is the Q factor? > > 4.2 - Explain what you mean by "at-most K paths". Define K. > > 4.2 - Why is there assumed to be one IV process and multiple RWA processes? > > General: Would it make sense to include a discussion of the order in which > PCE, WA, and IV should be done to avoid redundant computation? > > > Editorial Comments: > > Missing acronyms expansions: ADM, NEs, OSNR, DGD, PXCs, and OADMs > > > Acee-Lindems-MacBook-Pro:Desktop ealflin$ diff draft-ietf-ccamp-wson- > impairments-07.txt.orig draft-ietf-ccamp-wson-impairments-07.txt > 136c136 > < As an optical signal progresses along its path it may be altered by > --- > > As an optical signal progresses along its path, it may be altered by > 142c142 > < used, the types and placement of various optical devices and the > --- > > used, the types and placement of various optical devices, and the > 149c149 > < a WSON, a combination of path continuity, resource availability and > --- > > a WSON, a combination of path continuity, resource availability, and > 157c157 > < that use time division multiplexing, and WDM. The Path Computation > --- > > that use time division multiplexing and WDM. The Path Computation > 189c189 > < CWDM: Coarse Wavelength Division Multiplexing. > --- > > CWDM: Coarse Wavelength Division Multiplexing > 191c191 > < DWDM: Dense Wavelength Division Multiplexing. > --- > > DWDM: Dense Wavelength Division Multiplexing > 193c193 > < FOADM: Fixed Optical Add/Drop Multiplexer. > --- > > FOADM: Fixed Optical Add/Drop Multiplexer > 195c195 > < GMPLS: Generalized Multi-Protocol Label Switching. > --- > > GMPLS: Generalized Multi-Protocol Label Switching > 204c204 > < OXC: Optical cross connect. An optical switching element in which a > --- > > OXC: Optical cross connect - An optical switching element in which a > 207c207 > < PCC: Path Computation Client. Any client application requesting a > --- > > PCC: Path Computation Client - Any client application requesting a > 210c210 > < PCE: Path Computation Element. An entity (component, application, or > --- > > PCE: Path Computation Element - An entity (component, application, or > 219c219 > < PCEP: PCE Communication Protocol. The communication protocol between > --- > > PCEP: PCE Communication Protocol - The communication protocol between > 222c222 > < ROADM: Reconfigurable Optical Add/Drop Multiplexer. A wavelength > --- > > ROADM: Reconfigurable Optical Add/Drop Multiplexer - A wavelength > 226c226 > < RWA: Routing and Wavelength Assignment. > --- > > RWA: Routing and Wavelength Assignment > 247c247 > < WDM: Wavelength Division Multiplexing. > --- > > WDM: Wavelength Division Multiplexing > 281c281 > < cross connects to increase network flexibility. In such cases > --- > > cross connects to increase network flexibility. In such cases, > 335,336c335,336 > < contains transparent elements and electro-optical elements such as > < OEO regenerations. In such networks a generic light path can go > --- > > contain transparent elements and electro-optical elements such as > > OEO regenerations. In such networks, a generic light path can go > 341,342c341,342 > < (i) wavelength conversion to assist RWA to avoid wavelength blocking. > < This is the impairment free case covered by [RFC6163]. > --- > > (i) Due to wavelength conversion to assist RWA to avoid wavelength > > blocking. This is the impairment free case covered by [RFC6163]. > 344,345c344,345 > < (ii) the optical signal without regeneration would be too degraded > < to meet end to end BER requirements. This is the case when RWA > --- > > (ii) The optical signal without regeneration would be too degraded > > to meet end-to-end BER requirements. This is the case when RWA > 349c349 > < In the latter case an optical path can be seen as a set of transparent > --- > > In the latter case, an optical path can be seen as a set of transparent > 371,372c371,372 > < constraints that an impairment aware optical control plane may have > < to operate under. These requirements and constraints motivate the IA- > --- > > constraints under which an impairment aware optical control plane may have > > to operate. These requirements and constraints motivate the IA- > 396,397c396,397 > < In this case impairments are only taken into account during network > < design and after that, for example during optical path computation, > --- > > In this case, impairments are only taken into account during network > > design. After that, for example during optical path computation, > 452c452 > < channel interfaces to multi-channel DWDM systems only the single > --- > > channel interfaces to multi-channel DWDM systems, only the single > 456c456 > < available. Note however the overall impact of a black link at the > --- > > available. However, note that the overall impact of a black link at the > 461c461 > < spans and to estimate the validity of optical paths. For example, > --- > > spans in order to estimate the validity of optical paths. For example, > 468c468 > < for optical networks with "black links" (path) could not be performed > --- > > for optical networks with "black links" in the path could not be performed > 473c473 > < entity. Such a vendor specific IA computation, could utilize > --- > > entity. Such a vendor specific IA computation could utilize > 477c477 > < In the following the term "black links" will be used to describe > --- > > In the following, the term "black links" will be used to describe > 479c479 > < networks. From the control plane perspective the following options > --- > > networks. From the control plane perspective, the following options > 493,495c493,495 > < computation entity. The difficulty here is for larger networks > < such a list of paths along with any wavelength constraints could > < get unmanageably large. > --- > > computation entity. The difficulty here is that such a list of > > paths along with any wavelength constraints could get unmanageably > > large as the size of the network increases. > 497,498c497,498 > < 2. The authority in control of the "black links" could provide a PCE > < like entity a list of viable paths/wavelengths between two > --- > > 2. The authority in control of the "black links" could provide a > > PCE-like entity that returns a list of viable paths/wavelengths between two > 500,501c500,501 > < and can reduce the scaling issue previously mentioned. Such a PCE > < like entity would not need to perform a full RWA computation, > --- > > and can reduce the scaling issue previously mentioned. Such a PCE-like > > entity would not need to perform a full RWA computation, > 563c563 > < Starting from functional block on the left the Optical Interface > --- > > Starting from functional block on the left, the Optical Interface > 565,567c565,567 > < defines the properties at the path end points. Even the no-impairment > < case like scenario B in section 4.1.1 needs to consider a minimum set > < of interface characteristics. In such case only a few parameters used > --- > > defines the properties at the path end-points. Even the impairment-free > > case, like scenario B in section 4.1.1, needs to consider a minimum set > > of interface characteristics. In such case, only a few parameters used > 569,570c569,570 > < [RFC6163]). For the impairment-aware case these parameters may be > < sufficient or not depending on the accepted level of approximation > --- > > [RFC6163]). For the impairment-aware case, these parameters may or may > > not be sufficient depending on the accepted level of approximation > 572c572 > < consider a set of interface parameters during an Impairment > --- > > consider a set of interface parameters during the Impairment > 580,582c580,582 > < Options for this will be given in the next section on architectural > < alternatives. This block implementation (e.g. through routing, > < signaling or PCE) may influence the way the control plane distributes > --- > > Architectural alternatives to acommplish this are provided in > > section 4.2. This block implementation (e.g., through routing, > > signaling, or PCE) may influence the way the control plane distributes > 586,587c586,587 > < Depending on the IA level of approximation this function can be more > < or less complex. For example in case of no IA only the signal class > --- > > Depending on the IA level of approximation, this function can be more > > or less complex. For example, in the case of no IA, only the signal class > 599c599 > < taken in the physical modeling (worst-case, statistical or based on > --- > > taken in the physical modeling (worst-case, statistical, or based on > 602,603c602,603 > < marking some paths as not-feasible while they are very likely to be > < feasible in reality. > --- > > marking some paths as not-feasible which are very likely to be, in > > reality, feasible. > 609c609 > < From a control plane point of view optical impairments are additional > --- > > From a control plane point of view, optical impairments are additional > 614c614 > < Validation (estimation) (IV). > --- > > Validation (IV), i.e., estimation. > 618c618 > < point of view the following three forms of impairment validation will > --- > > point of view, the following three forms of impairment validation will > 623c623 > < In this case an Impairment Validation (IV) process furnishes a set of > --- > > In this case, an Impairment Validation (IV) process furnishes a set of > 630c630 > < discloses optical impairment information. Note that that this case > --- > > discloses optical impairment information. Note that this case > 634c634 > < In this case the control plane simply makes use of candidate paths > --- > > In this case, the control plane simply makes use of candidate paths > 636c636 > < is when the path validity is assessed within the control plane. The > --- > > is to assess the path validity within the control plane. The > 656c656 > < In this case an IV process is given a particular path and wavelength > --- > > In this case, an IV process is given a particular path and wavelength > 667c667 > < In this case impairments to a path are computed at a single entity. > --- > > In this case, impairments to a path are computed at a single entity. > 669c669 > < gathered from network elements. Depending how information is gathered > --- > > gathered from network elements. Depending how information is gathered, > 676c676 > < as OSNR, dispersion, DGD, etc. may be accumulated along the path via > --- > > as OSNR, dispersion, DGD, etc., may be accumulated along the path via > 679c679 > < measures reach the destination node a decision on the impairment > --- > > measures reach the destination node, a decision on the impairment > 685,686c685,686 > < The Control Plane must not preclude the possibility to operate one or > < all the above cases concurrently in the same network. For example > --- > > The Control Plane must not preclude the possibility to concurrently > > perform one or all the above cases in the same network. For example, > 690c690 > < same network however the control plane may compute a path outside the > --- > > same network, however, the control plane may compute a path outside the > 695c695 > < computation architectures and reviews some of their respective > --- > > computation architectures and review some of their respective > 708c708 > < solutions can be achieved if the path computation entity (PCE) can > --- > > solutions can be achieved if the Path Computation Entity (PCE) can > 710c710 > < wavelength assignment and impairment validation. > --- > > wavelength assignment, and impairment validation. > 718c718 > < Separating the processes of routing, WA and/or IV can reduce the need > --- > > Separating the processes of routing, WA, and/or IV can reduce the need > 721c721 > < [RFC6163]. In addition, as was discussed some impairment information > --- > > [RFC6163]. In addition, as was discussed, some impairment information > 724c724 > < precision it may be advantageous to offload this computation to a > --- > > precision, it may be advantageous to offload this computation to a > 735c735 > < validation is typically wavelength dependent hence combining WA > --- > > validation is typically wavelength dependent. Hence, combining WA > 743c743 > < selected path and wavelength. If IV comes first it would need to > --- > > selected path and wavelength. If IV comes first, it would need to > 749,751c749,751 > < In the non-impairment RWA situation [RFC6163] it was shown that a > < distributed wavelength assignment (WA) process carried out via > < signaling can eliminate the need to distribute wavelength > --- > > In the non-impairment RWA situation [RFC6163], it was shown that a > > distributed wavelength assignment (WA) process, carried out via > > signaling, can eliminate the need to distribute wavelength > 761,762c761,762 > < characteristics of network elements and links via routing protocols > < or by other means. So the following conceptual options belong to this > --- > > characteristics of network elements and links by routing protocols > > or other means. So the following conceptual options belong to this > 779,781c779,782 > < all wavelengths that could be used. This is somewhat windowed down as > < potential wavelengths are discovered to be in use, but could be a > < significant burden for lightly loaded high channel count networks. > --- > > all wavelengths that could be used. The amount of information is redunced > > somewhat as potential wavelengths are discovered to be in use, but could > > be a significant burden for lightly loaded network with high channel > > counts. > 785c786 > < Figure 2 shows process flows for three main architectural > --- > > Figure 2 shows process flows for the three main architectural > 787c788 > < sufficient. Figure 3 shows process flows for two main architectural > --- > > sufficient. Figure 3 shows process flows for the two main architectural > 841c842 > < The advantages, requirements and suitability of these options are as > --- > > The advantages, requirements, and suitability of these options are as > 847c848 > < entity enabling highest potential optimality and efficiency in IA- > --- > > entity enabling the highest potential optimality and efficiency in IA- > 870c871 > < and RWA are very different and prone to specialization. > --- > > and RWA are very different and conducive to specialization. > 874c875 > < In this alternative a signaling protocol may be extended and > --- > > In this alternative, a signaling protocol may be extended and > 877c878 > < optimality of optimality as (a) or (b), it does not require > --- > > optimality as (a) or (b), it does not require > 903c904 > < The advantages, requirements and suitability of these detailed > --- > > The advantages, requirements, and suitability of these detailed > 909,911c910,912 > < computation entity enabling highest potential optimality and > < efficiency in IA-RWA; then has a separate entity performing detailed > < impairment validation. In the case of "black links" the authority > --- > > computation entity enabling the highest potential optimality and > > efficiency in IA-RWA while a separate entity performs detailed > > impairment validation. In the case of "black links", the authority > 925c926 > < high degree of potential optimality and efficiency in IA-RWA; then a > --- > > high degree of potential optimality and efficiency in IA-RWA while a > 963,966c964,967 > < As previously discussed most IA-RWA scenarios to a greater or lesser > < extent rely on a common impairment information model. A number of > < ITU-T recommendations cover detailed as well as approximate > < impairment characteristics of fibers and a variety of devices and > --- > > As previously discussed, most IA-RWA scenarios rely, to a greater or lesser > > extent, on a common impairment information model. A number of > > ITU-T recommendations cover detailed, as well as, approximate > > impairment characteristics of fibers, a variety of devices, and > 979,980c980,981 > < the networks composed of a single WDM line system vendor combined > < with OADMs and/or PXCs from potentially multiple other vendors, this > --- > > networks composed of a single WDM line system vendor combined > > with OADMs and/or PXCs from potentially multiple other vendors. This > 982,984c983,985 > < planed in the future that [G.680] will include networks incorporating > < line systems from multiple vendors as well as OADMs and/or PXCs from > < potentially multiple other vendors, this is known as situation 2 and > --- > > planned in the future that [G.680] will include networks incorporating > > line systems from multiple vendors, as well as, OADMs and/or PXCs kfrom > > potentially from multiple other vendors. This is known as situation 2 and > 990c991 > < distributed IV case one needs to standardize the accumulated > --- > > distributed IV case, one needs to standardize the accumulated > 996c997 > < and in what form for the protocol would need to be standardized for > --- > > and in what form would need to be standardized for protocol > 1005c1006 > < Different approaches to path/wavelength impairment validation gives > --- > > Different approaches to path/wavelength impairment validation give > 1008c1009 > < paths GMPLS routing may be used to distribute the impairment > --- > > paths, GMPLS routing may be used to distribute the impairment > 1012,1013c1013,1014 > < Depending on the computational alternative the routing protocol may > < need to advertise information necessary to impairment validation > --- > > Depending on the computational alternative, the routing protocol may > > need to advertise information necessary to the impairment validation > 1015,1018c1016,1019 > < high amount of data that need to be advertised. Such issue can be > < addressed separating data that need to be advertised rarely and data > < that need to be advertised more frequently or adopting other form of > < awareness solutions described in previous sections (e.g. centralized > --- > > volume of data that needs to be advertised. Such issue can be > > addressed by separating data that need to be advertised rarely from data > > that need to be advertised more frequently or adopting the other forms of > > awareness solutions as described in previous sections (e.g., centralized > 1029,1030c1030,1031 > < In term of approximated scenario (see Section 4.1.1.) the model > < defined by [G.680] will apply and routing protocol will need to > --- > > In term of approximated scenario (see Section 4.1.1.), the model > > defined by [G.680] will apply and the routing protocols will need to > 1033c1034 > < In the case of distributed-IV no new demands would be placed on the > --- > > In the case of distributed-IV, no new demands would be placed on the > 1054c1055 > < In section 4.3. a number of computation architectural alternatives > --- > > In section 4.3, a number of computation architectural alternatives > 1058,1059c1059,1060 > < cooperating PCEs, and the impacts on the PCEP protocol. This document > < is providing this evaluation to aid solutions work. The protocol > --- > > cooperating PCEs, and the impacts on the PCEP. This document > > provide this evaluation to aid solutions work. The protocol > 1085c1086 > < wavelength. If the computations could not complete successfully it > --- > > wavelength. If the computations could not complete successfully, it > 1087,1088c1088,1089 > < it is of interest to know if this was due to lack of wavelength > < availability or impairment considerations or both. The information > --- > > it is of interest to know if failure was due to lack of wavelength > > availability, impairment considerations, or both. The information > 1098c1099 > < functionality can be added to one of previously defined entities. > --- > > functionality could be added to one of previously defined entities. > 1100c1101 > < process coordinator. The roles, responsibilities and information > --- > > process coordinator. The roles, responsibilities, and information > 1107,1108c1108,1109 > < as needed during RWA computations. In particular it needs to know to > < use the Candidates-PCE to obtain potential set of routes and > --- > > as needed during RWA computations. In particular, it needs to know to > > use the Candidates-PCE to obtain the potential set of routes and > 1130c1131 > < computation. It needs not take into account current link wavelength > --- > > computation. It need not take into account current link wavelength > 1139,1140c1140,1141 > < initiating PCC. (Note: RWA-Coord PCE is also a PCC with respect to > < the IV-Candidate) > --- > > initiating PCC. Note that the RWA-Coord PCE is also a PCC with respect to > > the IV-Candidate. > 1174c1175 > < Coordinating-PCE and the IV-Candidates-PCE. > --- > > Coordinating-PCE, and the IV-Candidates-PCE. > 1176c1177 > < In step (a) the PCC requests a path meeting specified quality > --- > > In step (a), the PCC requests a path meeting specified quality > 1179,1181c1180,1182 > < associated parameters. In step (b) the RWA-Coordinating-PCE requests > < up to K candidate paths between nodes A and Z and associated > < acceptable wavelengths. In step (c) The IV-Candidates PCE returns > --- > > associated parameters. In step (b), the RWA-Coordinating-PCE requests > > up to K candidate paths and their associated acceptable wavelengths > > between nodes A and Z . In step (c), the IV-Candidates PCE returns > 1183c1184 > < paths and wavelengths as input (e.g. a constraint) to its RWA > --- > > paths and wavelengths as input (e.g., a constraint) to its RWA > 1191c1192 > < computation. In step (d) the RWA-Coordinating PCE returns the overall > --- > > computation. In step (d), the RWA-Coordinating PCE returns the overall > 1196c1197 > < Previously Figure 3 showed two cases where a separate detailed > --- > > Previously, Figure 3 showed two cases where a separate detailed > 1200c1201 > < the PCC it is possible to keep the interactions with this separate > --- > > the PCC, it is possible to keep the interactions with this separate > 1211c1212 > < will furnish signal characteristics, quality requirements, path > --- > > will furnish signal characteristics, quality requirements, path, > 1216c1217 > < actually be met. In the case where the impairment validation fails > --- > > actually be met. In the case where the impairment validation fails, > 1218c1219 > < quantify the failure, e.g., so a judgment can be made whether to > --- > > quantify the failure, e.g., so that a judgment can be made whether to > 1221c1222 > < Figure 6 shows a sequence diagram for the interactions for the > --- > > Figure 6 shows a sequence diagram for the interactions corresponding to the > 1223c1224 > < PCC, RWA-PCE (acting as coordinator), IV-Candidates-PCE and the IV- > --- > > PCC, RWA-PCE (acting as coordinator), IV-Candidates-PCE, and the IV- > 1226c1227 > < In step (a) the PCC requests a path meeting specified quality > --- > > In step (a), the PCC requests a path meeting specified quality > 1229,1231c1230,1232 > < associated parameters. In step (b) the RWA-Coordinating-PCE requests > < up to K candidate paths between nodes A and Z and associated > < acceptable wavelengths. In step (c) The IV-Candidates-PCE returns > --- > > associated parameters. In step (b), the RWA-Coordinating-PCE requests > > up to K candidate paths and their associated acceptable wavelengths > > between nodes A and Z. In step (c), the IV-Candidates-PCE returns > 1233,1234c1234,1235 > < paths and wavelengths as input (e.g. a constraint) to its RWA > < computation. In step (d) the RWA-Coordinating-PCE request a detailed > --- > > paths and wavelengths as input (e.g., a constraint) to its RWA > > computation. In step (d), the RWA-Coordinating-PCE requests a detailed > 1236,1237c1237,1238 > < (e) the IV-Detailed-PCE returns the results of the validation to the > < RWA-Coordinating-PCE. Finally in step (f)IA-RWA-Coordinating PCE > --- > > (e), the IV-Detailed-PCE returns the results of this validation to the > > RWA-Coordinating-PCE. Finally in step (f), the IA-RWA-Coordinating PCE > 1277c1278 > < Coordinating-PCE, IV-Candidates-PCE and IV-Detailed-PCE. > --- > > Coordinating-PCE, IV-Candidates-PCE, and IV-Detailed-PCE. > 1285c1286 > < architecture is put into use within a network it will by its nature > --- > > architecture is put into use within a network, it will by its nature > 1290c1291 > < work will address any issues on the use of impairment information. > --- > > work will address any issues on the protection of impairment information. > > Thanks, > Acee From leeyoung@huawei.com Mon Oct 10 10:32:39 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6407621F8C6B for ; Mon, 10 Oct 2011 10:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21fHNinOQjiK for ; Mon, 10 Oct 2011 10:32:37 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 10BFC21F8C6A for ; Mon, 10 Oct 2011 10:32:35 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSV00GD5228C0@usaga02-in.huawei.com> for rtg-dir@ietf.org; Mon, 10 Oct 2011 12:32:33 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LSV00IF2228ES@usaga02-in.huawei.com> for rtg-dir@ietf.org; Mon, 10 Oct 2011 12:32:32 -0500 (CDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 10 Oct 2011 10:32:30 -0700 Received: from DFWEML501-MBX.china.huawei.com ([10.124.31.87]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Mon, 10 Oct 2011 10:32:25 -0700 Date: Mon, 10 Oct 2011 17:32:25 +0000 From: Leeyoung In-reply-to: <4E92F104.6050808@labn.net> X-Originating-IP: [10.47.128.252] To: Lou Berger Message-id: <7AEB3D6833318045B4AE71C2C87E8E171817F71C@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, zh-CN Thread-topic: [RTG-DIR] RtgDir review: draft-ietf-ccamp-attribute-bnf-02.txt Thread-index: AQHMh09XiLds9zA5bkGk/Tu3a3mad5V11fHg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7AEB3D6833318045B4AE71C2C87E8E171817F447@DFWEML501-MBX.china.huawei.com> <4E92F104.6050808@labn.net> Cc: "draft-ietf-ccamp-attribute-bnf.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-attribute-bnf-02.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 17:32:39 -0000 Lou, That's better. I have no more issue with this document. Young -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Monday, October 10, 2011 8:20 AM To: Leeyoung Cc: rtg-ads@tools.ietf.org; draft-ietf-ccamp-attribute-bnf.all@tools.ietf.org; rtg-dir@ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-attribute-bnf-02.txt Young, Thank you for the comments. Please see below for in-line responses. Lou On 10/7/2011 5:26 PM, Leeyoung wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review. The purpose > of the review is to provide assistance to the Routing ADs. For more > information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-ccamp-attribute-bnf-02.txt > > Reviewer: Young Lee > Review Date: 7 October 2011 > IETF LC End Date: 10 October 2011 > Intended Status: Standard track > > *Summary:* > I have no major concerns about this document that I think should be > resolved before publication. > > *Comments:* > This document is clearly written and easy to understand. > > *Major Issues:* > No major issues found. > > *Minor Issues:* > Section 3.2.1 > > > I am not sure if I understand this compatibility section written as follows: > > A node that does not support the LSP Attribute object formatting as > defined in this section will interpret the first present LSP > Attribute object as representing LSP operational status even when it > is intended to represent S2L sub-LSP status. It is unclear if this > is a significant issue as the LSP Attribute object is currently > considered to be an unsuitable mechanism for reporting operational > status of P2MP LSPs, for example see Section 2.1 of [NO-PHP-OOB]. > The intent of this document is to correct this limitation and it is > expected that networks that wish to make use of such operational > reporting will deploy this extension. > > If the node that does not support this new LSP attribute object, how can > it interprets the first > Present LSP Attribute object as LSP operational status if the LSP > attribute object is not a suitable > mechanism currently for reporting operational status of P2MP LSPs? > > It sounds like a contradictory statement as I read. Please clarify this > section if needed. Does the following revision clarify the paragraph? OLD: > A node that does not support the LSP Attribute object formatting as > defined in this section will interpret the first present LSP > Attribute object as representing LSP operational status even when it > is intended to represent S2L sub-LSP status. NEW: A node that supports [RFC4875] and [RFC5420], but not this document, will interpret the first LSP Attribute object present in a received message, which is formatted as described in this document, as representing LSP operational status rather than S2L sub-LSP status. Lou > > > *Nits:* > None identified > > > From lberger@labn.net Mon Oct 10 10:45:24 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857D521F8591 for ; Mon, 10 Oct 2011 10:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.628 X-Spam-Level: X-Spam-Status: No, score=-99.628 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdfFdTV7jvWG for ; Mon, 10 Oct 2011 10:45:23 -0700 (PDT) Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id CDA7021F84CF for ; Mon, 10 Oct 2011 10:45:23 -0700 (PDT) Received: (qmail 29145 invoked by uid 0); 10 Oct 2011 17:45:22 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 10 Oct 2011 17:45:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=nvzu5zIXX/U1UtTmHph1R7XjOLi7GAie2FB49H13vy4=; b=G4791I/ymoWex5MpEc0Izs13iI8IN3/9qpovs+K/Tyep23hjobRKwHDXNMAgHbK+l8wtbUwOiuv0kpgbaUj+XzZPhycbW/+Z7ArpGJawNH661+djDdxAR9//GRRgt9FE; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RDJuk-0006mX-AJ; Mon, 10 Oct 2011 11:45:22 -0600 Message-ID: <4E932F34.6040607@labn.net> Date: Mon, 10 Oct 2011 13:45:24 -0400 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: Leeyoung References: <7AEB3D6833318045B4AE71C2C87E8E171817F447@DFWEML501-MBX.china.huawei.com> <4E92F104.6050808@labn.net> <7AEB3D6833318045B4AE71C2C87E8E171817F71C@DFWEML501-MBX.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E171817F71C@DFWEML501-MBX.china.huawei.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-attribute-bnf.all@tools.ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-attribute-bnf-02.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 17:45:24 -0000 Thanks. Lou On 10/10/2011 1:32 PM, Leeyoung wrote: > Lou, > > That's better. I have no more issue with this document. > > Young > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Monday, October 10, 2011 8:20 AM > To: Leeyoung > Cc: rtg-ads@tools.ietf.org; draft-ietf-ccamp-attribute-bnf.all@tools.ietf.org; rtg-dir@ietf.org > Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-ccamp-attribute-bnf-02.txt > > Young, > Thank you for the comments. Please see below for in-line responses. > > Lou > > On 10/7/2011 5:26 PM, Leeyoung wrote: >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft. >> The Routing Directorate seeks to review all routing or routing-related >> drafts as they pass through IETF last call and IESG review. The purpose >> of the review is to provide assistance to the Routing ADs. For more >> information about the Routing Directorate, please see >> http://www.ietf.org/iesg/directorate/routing.html >> >> Although these comments are primarily for the use of the Routing ADs, it >> would be helpful if you could consider them along with any other IETF >> Last Call comments that you receive, and strive to resolve them through >> discussion or by updating the draft. >> >> Document: draft-ietf-ccamp-attribute-bnf-02.txt >> >> Reviewer: Young Lee >> Review Date: 7 October 2011 >> IETF LC End Date: 10 October 2011 >> Intended Status: Standard track >> >> *Summary:* >> I have no major concerns about this document that I think should be >> resolved before publication. >> >> *Comments:* >> This document is clearly written and easy to understand. >> >> *Major Issues:* >> No major issues found. >> >> *Minor Issues:* >> Section 3.2.1 >> >> >> I am not sure if I understand this compatibility section written as follows: >> >> A node that does not support the LSP Attribute object formatting as >> defined in this section will interpret the first present LSP >> Attribute object as representing LSP operational status even when it >> is intended to represent S2L sub-LSP status. It is unclear if this >> is a significant issue as the LSP Attribute object is currently >> considered to be an unsuitable mechanism for reporting operational >> status of P2MP LSPs, for example see Section 2.1 of [NO-PHP-OOB]. >> The intent of this document is to correct this limitation and it is >> expected that networks that wish to make use of such operational >> reporting will deploy this extension. >> >> If the node that does not support this new LSP attribute object, how can >> it interprets the first >> Present LSP Attribute object as LSP operational status if the LSP >> attribute object is not a suitable >> mechanism currently for reporting operational status of P2MP LSPs? >> >> It sounds like a contradictory statement as I read. Please clarify this >> section if needed. > > Does the following revision clarify the paragraph? > > OLD: >> A node that does not support the LSP Attribute object formatting as >> defined in this section will interpret the first present LSP >> Attribute object as representing LSP operational status even when it >> is intended to represent S2L sub-LSP status. > NEW: > A node that supports [RFC4875] and [RFC5420], but not this > document, will interpret the first LSP Attribute object present in > a received message, which is formatted as described in this > document, as representing LSP operational status rather than S2L > sub-LSP status. > > Lou > >> >> >> *Nits:* >> None identified >> >> >> > > > > From enkechen@cisco.com Tue Oct 11 11:26:25 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E64221F8F39 for ; Tue, 11 Oct 2011 11:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1u3tz2cbxM4 for ; Tue, 11 Oct 2011 11:26:24 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id B73BF21F8F3B for ; Tue, 11 Oct 2011 11:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=enkechen@cisco.com; l=5247; q=dns/txt; s=iport; t=1318357584; x=1319567184; h=message-id:date:from:mime-version:to:cc:subject; bh=4zeFHP+fmQJg8M6Bm24frGO7P6shopEk6pPKYDOkMbM=; b=g6BnNg+L1LP7dmPqvEqRkl5yw/WR2b5DF7JHx8jRbub1tQN4SC8CxsUC doiX+lxtDN1FNOkYwlmfsH97RP+AEbhgKZbhytLJkF17kISQArC/AmWz7 TikvGJZ4BYtMBWVKYllfYAUwqT9Qq084bBU8G1oE/GrGoKdtO1kjl8mEp Q=; X-IronPort-AV: E=Sophos;i="4.68,524,1312156800"; d="scan'208,217";a="7235073" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 11 Oct 2011 18:26:24 +0000 Received: from enkechen-mac.local ([10.155.35.222]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9BIQOie015937; Tue, 11 Oct 2011 18:26:24 GMT Message-ID: <4E948A76.7050507@cisco.com> Date: Tue, 11 Oct 2011 11:27:02 -0700 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: multipart/alternative; boundary="------------050108060905010200000005" Cc: rtg-dir@ietf.org, Enke Chen , draft-ietf-pim-port.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-pim-port-08.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 18:26:25 -0000 This is a multi-part message in MIME format. --------------050108060905010200000005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-pim-port-08.txt Reviewer: Enke Chen Review Date: October 10, 2011 IETF LC End Date: October 20, 2011 Intended Status: Standard track *Summary:* I have no major concerns about this document that I think should be resolved before publication. *Comments:* This document is clearly written and easy to understand. *Major Issues:* No major issues found. *Minor Issues:* None identified *Nits:* None identified --------------050108060905010200000005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-pim-port-08.txt

Reviewer: Enke Chen
Review Date: October 10, 2011
IETF LC End Date: October 20, 2011
Intended Status: Standard track

Summary:
I have no major concerns about this document that I think should be resolved before publication.

Comments:
This document is clearly written and easy to understand.

Major Issues:
No major issues found. 

Minor Issues: 
None identified

Nits:
None identified

 

--------------050108060905010200000005-- From hejia@huawei.com Thu Oct 20 05:18:22 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7C821F8AFE for ; Thu, 20 Oct 2011 05:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLOz8KGuNsrP for ; Thu, 20 Oct 2011 05:18:21 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id D809721F8AF7 for ; Thu, 20 Oct 2011 05:18:20 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTD00IH166HKF@szxga03-in.huawei.com> for rtg-dir@ietf.org; Thu, 20 Oct 2011 20:18:18 +0800 (CST) Received: from szxrg01-dlp.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 <0LTD00K0Z66HMA@szxga03-in.huawei.com> for rtg-dir@ietf.org; Thu, 20 Oct 2011 20:18:17 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEP01669; Thu, 20 Oct 2011 20:18:05 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 20 Oct 2011 20:18:01 +0800 Received: from hejia (10.70.77.94) by smtpscn.huawei.com (10.82.67.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 20 Oct 2011 20:17:58 +0800 Date: Thu, 20 Oct 2011 20:17:58 +0800 From: Hejia X-Originating-IP: [10.70.77.94] To: rtg-ads@tools.ietf.org Message-id: <083201cc8f22$4e0ac350$ea2049f0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_9LlnjHXCjv2+gPVZ6YAhMw)" Content-language: zh-cn Thread-index: AcyPIk3beT9TOgILSumIYWm389fhmw== X-CFilter-Loop: Reflected Cc: rtg-dir@ietf.org, draft-ietf-mpls-tp-li-lb.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-li-lb-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 12:18:22 -0000 --Boundary_(ID_9LlnjHXCjv2+gPVZ6YAhMw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html. Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-tp-li-lb-07.txt Reviewer: Jia He Review Date: October 19, 2011 IETF LC End Date: Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: The title indicates that the draft defines lock and loopback functions for MPLS-TP. However, most parts in the draft use MPLS, e.g. MPLS networks, MPLS OAM, MPLS Sections. Please check through the whole draft and make necessary changes to keep consistent. Major Issues: Minor Issues 1) Clarification required on "updates RFC 6371" Section 1.1 gives clarifications on how it updates Section 7.1.1 of RFC 6371. " The mechanism defined in this document requires that a lock instruction is sent by management to both ends of the locked transport path and that the Lock Instruct message does not require a response. " IMHO, only the latter part of the text above, i.e. "the Lock Instruct message does not require a response", is related to Section 7.1.1 of RFC 6371 and indeed an update. The former part seems to be covered already in Section 7.1 of RFC 6371 by the following description. What has been updated? Could the authors give some clarifications? " Note that it is also possible to administratively lock (and unlock) an MPLS-TP transport path using two-side provisioning, where the NMS administratively puts both MEPs into an administrative lock condition. In this case, the LKI function is not required/used. " BTW, according to Section 7.1 of RFC 6371 (the above text), LKI function is not required/used when two-side provisioning by NMS is used. Is this true or not in this draft? 2) Section 3 gives the description below: " To properly lock a transport path (for example, to ensure that a loopback test can be performed), both directions of the transport path must be taken out of service so a Lock command is sent to the ^^^^^^^^^^^^^^^^^^^^^^^^^ MEPs at both ends of the path. This ensures that no traffic is sent ^^^^^^^^^^^^^^^^^^^^^^^^ in either direction. Thus, the Lock function can be realized entirely ^^^^^^^^ using the management plane. ^^^^^^^^^^^^^^^^^^^^^^^ " followed by " ...In order to provide additional coordination, an LI OAM message can additionally be sent. ^^^^^^^^^^ " , which gives an impression that LI OAM message is optional when a lock command is sent to both ends of a transport path. Besides, RFC 6371 indicates that LKI function is not required/used when two-side provisioning by NMS is used, which is already pointed out in Issue 1). However, Section 6.1 has the following description: " As soon as the transport path has been locked, the MEP MUST send an ^^^^ LI message targeting the MEP at the other end of the locked transport path. " , which indicates LI MUST be sent. Does it contradict with Section 3 or RFC 6371? 3) Section 2.2 has the following term 3.1) MPLS-TP LSP: Bidirectional Label Switch Path It is not proper to regard MPLS-TP LSP as "Bidirectional Label Switch Path" since MPLS-TP LSP can be unidirectional (p2p, p2mp) as well. 3.2) Transport path: MPLS-TP LSP or MPLS PW MPLS PW or MPLS-TP PW? What about "MPLS-TP LSP or PW"? 4) Section 6.1 " - If the transport path can be identified, but there is no return path (for example, the transport path was unidirectional) then the lock cannot be applied by the receiving MEP. " Is this applicable for LB function or LI function? To my understanding, this is prerequisites for LB function but not necessarily for LI function since Lock Instruct message does not require a response. Nits: 1) Section 1, the second paragraph, s/applied to to Label Switched Paths/applied to Label Switched Paths, 2) Section 1, the fourth paragraph, s/the transport is locked/the transport path is locked 3) Section 4.1, the second paragraph, s/must e/must be 4) Section 4.1, the third paragraph, s/This possible for/This is possible for 5) Section 5.1, the first paragraph, s/Associated Channel Header (ACh)/Associated Channel Header (ACH) That's all. B.R. Jia --Boundary_(ID_9LlnjHXCjv2+gPVZ6YAhMw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hello,

 

I have been selected as the Routing Directorate reviewer = for this draft. The Routing Directorate seeks to review all routing or = routing-related drafts as they pass through IETF last call and IESG = review, and sometimes on special request. The purpose of the review is = to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please see http://www.iet= f.org/iesg/directorate/routing.html.

 

Although these comments are = primarily for the use of the Routing ADs, it would be helpful if you = could consider them along with any other IETF Last Call comments that = you receive, and strive to resolve them through discussion or by = updating the draft.

 

 

Document: = draft-ietf-mpls-tp-li-lb-07.txt

Reviewer: Jia = He

Review = Date: October 19, 2011

IETF LC End Date:

Intended Status: Standards = Track

 

Summary:

 

I have some minor concerns about = this document that I think should be resolved before = publication.

 

Comments:

 

The title indicates that the draft = defines lock and loopback functions for MPLS-TP. However, most parts in = the draft use MPLS, e.g. MPLS networks, MPLS OAM, MPLS Sections. Please = check through the whole draft and make necessary changes to keep = consistent.

 

Major Issues:

 

Minor = Issues

 

1) Clarification required on "updates RFC = 6371"

 

Section 1.1 gives clarifications on how it updates Section = 7.1.1 of RFC 6371.

 

"  The mechanism defined in this document = requires that a lock

   instruction is sent by management to both ends = of the locked

   transport path and that the Lock Instruct = message does not require a

   = response.

"

 

IMHO, only the latter part of the text above, i.e. = "the Lock Instruct message does not require a response", is = related to Section 7.1.1 of RFC 6371 and indeed an update. The former = part seems to be covered already in Section 7.1 of RFC 6371 by the = following description. What has been updated? Could the authors give = some clarifications?

 

"

   Note that it is also possible to = administratively lock (and unlock)

   an MPLS-TP transport = path using two-side provisioning, where the NMS

   administratively puts = both MEPs into an administrative lock

   condition. In this = case, the LKI function is not required/used.

"

 

BTW, according to Section 7.1 of = RFC 6371 (the above text), LKI function is not required/used when = two-side provisioning by NMS is used. Is this true or not in this draft? =

 

 

 

2) Section 3 gives the description = below:

 

"

   To properly lock a transport path (for = example, to ensure that a

   loopback test can be = performed), both directions of the transport

   path must be taken out = of service so a Lock command is sent to the

          =             &= nbsp;         = ^^^^^^^^^^^^^^^^^^^^^^^^^

   MEPs at both ends of = the path. This ensures that no traffic is sent

   = ^^^^^^^^^^^^^^^^^^^^^^^^

   in either direction. Thus, the Lock function = can be realized entirely

          =             &= nbsp;           &n= bsp;           &nb= sp;  ^^^^^^^^

   using the management = plane.

   = ^^^^^^^^^^^^^^^^^^^^^^^

"

 

followed by

 

"

...In order to provide additional = coordination, an LI OAM message can additionally be = sent.

          =             &= nbsp;           &n= bsp;           &nb= sp;         = ^^^^^^^^^^

"  

, which gives an impression that LI = OAM message is optional when a lock command is sent to both ends of a = transport path.

Besides, RFC 6371 indicates that LKI function is not = required/used when two-side provisioning by NMS is used, which is = already pointed out in Issue 1).

 

However, Section 6.1 has the = following description:

"

   As soon as the transport path has been locked, = the MEP MUST send an

          =             &= nbsp;           &n= bsp;           &nb= sp;  ^^^^

   LI message targeting the MEP at the other end = of the locked transport

   path.

 

"

, which indicates LI MUST be sent. = Does it contradict with Section 3 or RFC 6371?    =

 

 

 

3) Section 2.2 has the following = term

 

3.1) MPLS-TP LSP: = Bidirectional Label Switch Path

 

It is = not proper to regard MPLS-TP LSP as "Bidirectional Label Switch = Path" since MPLS-TP LSP can be unidirectional (p2p, p2mp) as well. =

 

3.2) Transport path: = MPLS-TP LSP or MPLS PW

 

MPLS PW or MPLS-TP PW? =

What about "MPLS-TP = LSP or PW"?

 

 

 

4) Section 6.1

 

"  - If the transport = path can be identified, but there is no return

     path (for = example, the transport path was unidirectional) then = the

     lock cannot be applied by the = receiving MEP.

"

Is this applicable for LB function or LI function? =

To my = understanding, this is prerequisites for LB function but not necessarily = for LI function since Lock Instruct message does not require a response. =

 

 

 

Nits:

 

1) Section 1, the second paragraph, s/applied to to Label = Switched Paths/applied to Label Switched Paths,

 

2) Section 1, the fourth paragraph, = s/the transport is locked/the transport path is = locked

 

3) Section 4.1, the second paragraph, s/must e/must = be

 

4) Section 4.1, the third paragraph, s/This possible = for/This is possible for

 

5) Section 5.1, the first paragraph, s/Associated Channel = Header (ACh)/Associated Channel Header (ACH)

 

 

 

That's all.

 

 

B.R.

Jia

= --Boundary_(ID_9LlnjHXCjv2+gPVZ6YAhMw)-- From leeyoung@huawei.com Fri Oct 21 05:31:44 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BDB21F8BF3 for ; Fri, 21 Oct 2011 05:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeaFvpaSMc2p for ; Fri, 21 Oct 2011 05:31:42 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id D2D8A21F8BE9 for ; Fri, 21 Oct 2011 05:31:41 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTF007891GTQZ@usaga02-in.huawei.com> for rtg-dir@ietf.org; Fri, 21 Oct 2011 07:31:41 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LTF00MRH1GT1Y@usaga02-in.huawei.com> for rtg-dir@ietf.org; Fri, 21 Oct 2011 07:31:41 -0500 (CDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 21 Oct 2011 05:31:33 -0700 Received: from DFWEML501-MBX.china.huawei.com ([10.124.31.87]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Fri, 21 Oct 2011 05:31:30 -0700 Date: Fri, 21 Oct 2011 12:31:30 +0000 From: Leeyoung X-Originating-IP: [10.18.29.181] To: "rtg-dir@ietf.org" , "ccamp-chairs@tools.ietf.org" Message-id: <7AEB3D6833318045B4AE71C2C87E8E171818232D@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, zh-CN Thread-topic: Routing-Directory Review of "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments" - draft-ietf-ccamp-wson-impairments-07.txt Thread-index: AcyHcDhDr14yzGLLTbmWYTQof9WvVgA61EbQAGTJcAABe+hnoAADvSeA X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AEly BCdp FQ1I GL2S GidQ HMaR J21I LJ4W NJOY NYVT OHK/ PMry QJCe QQiw Rjfg TUKU; 2; YwBjAGEAbQBwAC0AYwBoAGEAaQByAHMAQAB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcAOwByAHQAZwAtAGQAaQByAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {6A5ECF35-1725-4746-9994-FEE4542B4A4F}; bABlAGUAeQBvAHUAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Fri, 21 Oct 2011 12:31:25 GMT; RgBXADoAIABSAG8AdQB0AGkAbgBnAC0ARABpAHIAZQBjAHQAbwByAHkAIABSAGUAdgBpAGUAdwAgAG8AZgAgACIAQQAgAEYAcgBhAG0AZQB3AG8AcgBrACAAZgBvAHIAIAB0AGgAZQAgAEMAbwBuAHQAcgBvAGwAIABvAGYAIABXAGEAdgBlAGwAZQBuAGcAdABoACAAUwB3AGkAdABjAGgAZQBkACAATwBwAHQAaQBjAGEAbAAgAE4AZQB0AHcAbwByAGsAcwAgACgAVwBTAE8ATgApACAAdwBpAHQAaAAgAEkAbQBwAGEAaQByAG0AZQBuAHQAcwAiACAALQAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBjAGMAYQBtAHAALQB3AHMAbwBuAC0AaQBtAHAAYQBpAHIAbQBlAG4AdABzAC0AMAA3AC4AdAB4AHQA x-cr-puzzleid: {6A5ECF35-1725-4746-9994-FEE4542B4A4F} Subject: [RTG-DIR] FW: Routing-Directory Review of "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments" - draft-ietf-ccamp-wson-impairments-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 12:31:44 -0000 FYI. -----Original Message----- From: Leeyoung Sent: Friday, October 21, 2011 7:25 AM To: 'Acee Lindem' Cc: 'secdir@ietf.org'; 'iesg@ietf.org'; 'draft-ietf-ccamp-wson-impairments@tools.ietf.org'; 'adrian@olddog.co.uk' Subject: RE: Routing-Directory Review of "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments" - draft-ietf-ccamp-wson-impairments-07.txt Hi Acee, Thanks a lot for your feedback. I think we are merging. Please see in-line for my comment. If you are satisfied with these changes, I will update the revision. Thanks, Young -----Original Message----- From: Acee Lindem [mailto:acee.lindem@ericsson.com] Sent: Thursday, October 13, 2011 9:26 AM To: Leeyoung Subject: Re: Routing-Directory Review of "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments" - draft-ietf-ccamp-wson-impairments-07.txt Hi Young, On Oct 11, 2011, at 9:09 PM, Leeyoung wrote: > Hi Acee, > > Thanks for your thorough review and suggestions. Please see in-line if my response would satisfy you. Before I edit, I just wanted to know if these would be good enough for you. > > Thanks. > > Young > > -----Original Message----- > From: Acee Lindem [mailto:acee.lindem@ericsson.com] > Sent: Monday, October 10, 2011 12:16 PM > To: Greg Bernstein; Huawei danli; Leeyoung; Giovanni Martinelli > Cc: rtg-dir@ietf.org; ccamp-chairs@tools.ietf.org; Adrian Farrel > Subject: Routing-Directory Review of "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments" - draft-ietf-ccamp-wson-impairments-07.txt > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. > > > Document: draft-ietf-ccamp-wson-impairments-07.txt > Reviewer: Acee Lindem > Review Date: 2011-10-10 > IETF LC End Date: TBD > Intended Status: Informational > > Summary: > I have no major concerns about this document that I think must be > resolved before publication. I have some suggestions below. > > Major Issues: > No major issues found. > > Minor Issues: > The document is somewhat hard to read and I've included some editorial suggestions below. Some of tthese are subjective and style based. For example, I prefer a comma after a prepositional phase preceding an independent clause. Other suggested edits are obvious typos (so you'll need to look at them all ;^). > > Additionally, I'd suggest the following: > > Abstract: Mention the components included in the framework in the abstract and introduction > to set the context for the remainder of the document. > > Current Abstract: > > As an optical signal progresses along its path it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks. > This document provides a framework for applying GMPLS protocols and the PCE architecture to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. This document does not define optical data plane aspects; impairment parameters, measurement of, or assessment and qualification of a route, but rather it describes the architectural and information components for protocol solutions. > > Suggested Abstract: > > As an optical signal progresses along its path it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks. > This document provides a framework for applying GMPLS protocols and the PCE architecture to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. Specifically, this documents discusses key computing constraints, scenarios and impairment estimation processes. This document does not define optical data plane aspects; impairment parameters, measurement of, or assessment and qualification of a route, but rather it describes the architectural and information components for protocol solutions. That's better - do you think it should mention the architectural processes: Routing, Wavelength Assignment, and Impairment Validation. YOUNG>> I will add these processes in the abstract. The new text will look like as follows: As an optical signal progresses along its path it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks. This document provides a framework for applying GMPLS protocols and the PCE architecture to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. Specifically, this documents discusses key computing constraints, scenarios and architectural processes: Routing, Wavelength Assignment, and Impairment Validation. This document does not define optical data plane aspects; impairment parameters, measurement of, or assessment and qualification of a route, but rather it describes the architectural and information components for protocol solutions. > > 2 - Include "black link". > > Black links: Black links refer to tributary interfaces where only link characteristics are defined. This approach enables transverse compatibility at the single-channel point using a direct wavelength-multiplexing configuration. Ok. > > 4.1.1, Scenario D - The detailed case is designated as out of scope yet it is referred to > in later sections. For example, section 4.3. > > I am not sure where in Section 4.3 we are referring to Scenario D. All the discussions in section 4.3 are actually in the spirit of Scenario C - approximated impairment estimation. Then it is unclear to me what the difference is between IV and IV-Detailed in the remainder of the document. YOUNG>> I realized that Scenario D - Detailed is a confusing term since we use IV-Detailed in the remainder of the document. In section 4.1.1. Scenario D - the detailed case is now changed to "Accurate Impairment Computation." YOUNG>> I also added the following text: "All the variations of impairment validation discussed in this section is based on Scenario C (Approximated Impairment Estimation) as discussed in Section 4.1.1." is section 4.2. to make sure we are discussing all IV discussion in the spirit of Scenario C. > > 4.1.3 - What is the Q factor? > > The Q-factor provides a qualitative description of the receiver performance. It is a function of the signal to noise ratio (optical). The Q-factor suggests the minimum SNR required to obtain a specific BER for a given signal. (Would you like to suggest Q-factor in the definition?) Yes - that would be good. > > 4.2 - Explain what you mean by "at-most K paths". Define K. > > K refers to the "K" value in K-shortest path algorithm. I see I get a lot of Google hits on this but I had never heard of it before and I work on SPF and LFA. Could you add a definition and, possibly, a reference? YOUNG>> Yes. I will add the definition and reference as follows: K-shortest path algorithm refers to an algorithm that finds multiple (k) short paths connecting the source and the destination in a graph (allowing repeated vertices and edges in the paths). D. Eppstein. "Finding the k shortest paths," 35th IEEE Symp. Foundations of Comp. Sci., Santa Fe, 1994, pp. 154-165. > > 4.2 - Why is there assumed to be one IV process and multiple RWA processes? > > Actually section 4.2 shows a number of options as to how to do with R and WA with respect to IV. R and WA can be combined before IV; or sequentially R, WA and IV; or once R is determined WA can be done in a distributed fashion with IV on a hop by hop. > > General: Would it make sense to include a discussion of the order in which > PCE, WA, and IV should be done to avoid redundant computation? > > Figures 5 and 6 show each entity that involves R, WA and IV (detail, approximation) respectively. I thought these figures show non-redundant computation in a sequential manner. It is implied and maybe obvious to those familiar with optical path computation. However, it occurred to me that other functional distributions wouldn't work (at least not without lots of inefficiency ;^). YOUNG>> Actually I will add the following text in Section 5.4.3. "Please note that there is some inefficiency by separating the IV-Candidates-PCE from the IV-Detailed-PCE from a message flow perspective in order to achieve a high degree of potential optimality." Thanks, Acee > > Editorial Comments: > > Missing acronyms expansions: ADM, NEs, OSNR, DGD, PXCs, and OADMs > YOUNG>> I will add the following acronyms: ADM: Add Drop Multiplexer NEs: Network Elements OSNR: Optical Signal to Noise Ratio DGD: differential group delay PXCs: Photonic Cross Connects OADMs: Optical Add Drop Multiplexers > > Acee-Lindems-MacBook-Pro:Desktop ealflin$ diff draft-ietf-ccamp-wson-impairments-07.txt.orig draft-ietf-ccamp-wson-impairments-07.txt > 136c136 > < As an optical signal progresses along its path it may be altered by > --- >> As an optical signal progresses along its path, it may be altered by > 142c142 > < used, the types and placement of various optical devices and the > --- >> used, the types and placement of various optical devices, and the > 149c149 > < a WSON, a combination of path continuity, resource availability and > --- >> a WSON, a combination of path continuity, resource availability, and > 157c157 > < that use time division multiplexing, and WDM. The Path Computation > --- >> that use time division multiplexing and WDM. The Path Computation > 189c189 > < CWDM: Coarse Wavelength Division Multiplexing. > --- >> CWDM: Coarse Wavelength Division Multiplexing > 191c191 > < DWDM: Dense Wavelength Division Multiplexing. > --- >> DWDM: Dense Wavelength Division Multiplexing > 193c193 > < FOADM: Fixed Optical Add/Drop Multiplexer. > --- >> FOADM: Fixed Optical Add/Drop Multiplexer > 195c195 > < GMPLS: Generalized Multi-Protocol Label Switching. > --- >> GMPLS: Generalized Multi-Protocol Label Switching > 204c204 > < OXC: Optical cross connect. An optical switching element in which a > --- >> OXC: Optical cross connect - An optical switching element in which a > 207c207 > < PCC: Path Computation Client. Any client application requesting a > --- >> PCC: Path Computation Client - Any client application requesting a > 210c210 > < PCE: Path Computation Element. An entity (component, application, or > --- >> PCE: Path Computation Element - An entity (component, application, or > 219c219 > < PCEP: PCE Communication Protocol. The communication protocol between > --- >> PCEP: PCE Communication Protocol - The communication protocol between > 222c222 > < ROADM: Reconfigurable Optical Add/Drop Multiplexer. A wavelength > --- >> ROADM: Reconfigurable Optical Add/Drop Multiplexer - A wavelength > 226c226 > < RWA: Routing and Wavelength Assignment. > --- >> RWA: Routing and Wavelength Assignment > 247c247 > < WDM: Wavelength Division Multiplexing. > --- >> WDM: Wavelength Division Multiplexing > 281c281 > < cross connects to increase network flexibility. In such cases > --- >> cross connects to increase network flexibility. In such cases, > 335,336c335,336 > < contains transparent elements and electro-optical elements such as > < OEO regenerations. In such networks a generic light path can go > --- >> contain transparent elements and electro-optical elements such as >> OEO regenerations. In such networks, a generic light path can go > 341,342c341,342 > < (i) wavelength conversion to assist RWA to avoid wavelength blocking. > < This is the impairment free case covered by [RFC6163]. > --- >> (i) Due to wavelength conversion to assist RWA to avoid wavelength >> blocking. This is the impairment free case covered by [RFC6163]. > 344,345c344,345 > < (ii) the optical signal without regeneration would be too degraded > < to meet end to end BER requirements. This is the case when RWA > --- >> (ii) The optical signal without regeneration would be too degraded >> to meet end-to-end BER requirements. This is the case when RWA > 349c349 > < In the latter case an optical path can be seen as a set of transparent > --- >> In the latter case, an optical path can be seen as a set of transparent > 371,372c371,372 > < constraints that an impairment aware optical control plane may have > < to operate under. These requirements and constraints motivate the IA- > --- >> constraints under which an impairment aware optical control plane may have >> to operate. These requirements and constraints motivate the IA- > 396,397c396,397 > < In this case impairments are only taken into account during network > < design and after that, for example during optical path computation, > --- >> In this case, impairments are only taken into account during network >> design. After that, for example during optical path computation, > 452c452 > < channel interfaces to multi-channel DWDM systems only the single > --- >> channel interfaces to multi-channel DWDM systems, only the single > 456c456 > < available. Note however the overall impact of a black link at the > --- >> available. However, note that the overall impact of a black link at the > 461c461 > < spans and to estimate the validity of optical paths. For example, > --- >> spans in order to estimate the validity of optical paths. For example, > 468c468 > < for optical networks with "black links" (path) could not be performed > --- >> for optical networks with "black links" in the path could not be performed > 473c473 > < entity. Such a vendor specific IA computation, could utilize > --- >> entity. Such a vendor specific IA computation could utilize > 477c477 > < In the following the term "black links" will be used to describe > --- >> In the following, the term "black links" will be used to describe > 479c479 > < networks. From the control plane perspective the following options > --- >> networks. From the control plane perspective, the following options > 493,495c493,495 > < computation entity. The difficulty here is for larger networks > < such a list of paths along with any wavelength constraints could > < get unmanageably large. > --- >> computation entity. The difficulty here is that such a list of >> paths along with any wavelength constraints could get unmanageably >> large as the size of the network increases. > 497,498c497,498 > < 2. The authority in control of the "black links" could provide a PCE > < like entity a list of viable paths/wavelengths between two > --- >> 2. The authority in control of the "black links" could provide a >> PCE-like entity that returns a list of viable paths/wavelengths between two > 500,501c500,501 > < and can reduce the scaling issue previously mentioned. Such a PCE > < like entity would not need to perform a full RWA computation, > --- >> and can reduce the scaling issue previously mentioned. Such a PCE-like >> entity would not need to perform a full RWA computation, > 563c563 > < Starting from functional block on the left the Optical Interface > --- >> Starting from functional block on the left, the Optical Interface > 565,567c565,567 > < defines the properties at the path end points. Even the no-impairment > < case like scenario B in section 4.1.1 needs to consider a minimum set > < of interface characteristics. In such case only a few parameters used > --- >> defines the properties at the path end-points. Even the impairment-free >> case, like scenario B in section 4.1.1, needs to consider a minimum set >> of interface characteristics. In such case, only a few parameters used > 569,570c569,570 > < [RFC6163]). For the impairment-aware case these parameters may be > < sufficient or not depending on the accepted level of approximation > --- >> [RFC6163]). For the impairment-aware case, these parameters may or may >> not be sufficient depending on the accepted level of approximation > 572c572 > < consider a set of interface parameters during an Impairment > --- >> consider a set of interface parameters during the Impairment > 580,582c580,582 > < Options for this will be given in the next section on architectural > < alternatives. This block implementation (e.g. through routing, > < signaling or PCE) may influence the way the control plane distributes > --- >> Architectural alternatives to acommplish this are provided in >> section 4.2. This block implementation (e.g., through routing, >> signaling, or PCE) may influence the way the control plane distributes > 586,587c586,587 > < Depending on the IA level of approximation this function can be more > < or less complex. For example in case of no IA only the signal class > --- >> Depending on the IA level of approximation, this function can be more >> or less complex. For example, in the case of no IA, only the signal class > 599c599 > < taken in the physical modeling (worst-case, statistical or based on > --- >> taken in the physical modeling (worst-case, statistical, or based on > 602,603c602,603 > < marking some paths as not-feasible while they are very likely to be > < feasible in reality. > --- >> marking some paths as not-feasible which are very likely to be, in >> reality, feasible. > 609c609 > < From a control plane point of view optical impairments are additional > --- >> From a control plane point of view, optical impairments are additional > 614c614 > < Validation (estimation) (IV). > --- >> Validation (IV), i.e., estimation. > 618c618 > < point of view the following three forms of impairment validation will > --- >> point of view, the following three forms of impairment validation will > 623c623 > < In this case an Impairment Validation (IV) process furnishes a set of > --- >> In this case, an Impairment Validation (IV) process furnishes a set of > 630c630 > < discloses optical impairment information. Note that that this case > --- >> discloses optical impairment information. Note that this case > 634c634 > < In this case the control plane simply makes use of candidate paths > --- >> In this case, the control plane simply makes use of candidate paths > 636c636 > < is when the path validity is assessed within the control plane. The > --- >> is to assess the path validity within the control plane. The > 656c656 > < In this case an IV process is given a particular path and wavelength > --- >> In this case, an IV process is given a particular path and wavelength > 667c667 > < In this case impairments to a path are computed at a single entity. > --- >> In this case, impairments to a path are computed at a single entity. > 669c669 > < gathered from network elements. Depending how information is gathered > --- >> gathered from network elements. Depending how information is gathered, > 676c676 > < as OSNR, dispersion, DGD, etc. may be accumulated along the path via > --- >> as OSNR, dispersion, DGD, etc., may be accumulated along the path via > 679c679 > < measures reach the destination node a decision on the impairment > --- >> measures reach the destination node, a decision on the impairment > 685,686c685,686 > < The Control Plane must not preclude the possibility to operate one or > < all the above cases concurrently in the same network. For example > --- >> The Control Plane must not preclude the possibility to concurrently >> perform one or all the above cases in the same network. For example, > 690c690 > < same network however the control plane may compute a path outside the > --- >> same network, however, the control plane may compute a path outside the > 695c695 > < computation architectures and reviews some of their respective > --- >> computation architectures and review some of their respective > 708c708 > < solutions can be achieved if the path computation entity (PCE) can > --- >> solutions can be achieved if the Path Computation Entity (PCE) can > 710c710 > < wavelength assignment and impairment validation. > --- >> wavelength assignment, and impairment validation. > 718c718 > < Separating the processes of routing, WA and/or IV can reduce the need > --- >> Separating the processes of routing, WA, and/or IV can reduce the need > 721c721 > < [RFC6163]. In addition, as was discussed some impairment information > --- >> [RFC6163]. In addition, as was discussed, some impairment information > 724c724 > < precision it may be advantageous to offload this computation to a > --- >> precision, it may be advantageous to offload this computation to a > 735c735 > < validation is typically wavelength dependent hence combining WA > --- >> validation is typically wavelength dependent. Hence, combining WA > 743c743 > < selected path and wavelength. If IV comes first it would need to > --- >> selected path and wavelength. If IV comes first, it would need to > 749,751c749,751 > < In the non-impairment RWA situation [RFC6163] it was shown that a > < distributed wavelength assignment (WA) process carried out via > < signaling can eliminate the need to distribute wavelength > --- >> In the non-impairment RWA situation [RFC6163], it was shown that a >> distributed wavelength assignment (WA) process, carried out via >> signaling, can eliminate the need to distribute wavelength > 761,762c761,762 > < characteristics of network elements and links via routing protocols > < or by other means. So the following conceptual options belong to this > --- >> characteristics of network elements and links by routing protocols >> or other means. So the following conceptual options belong to this > 779,781c779,782 > < all wavelengths that could be used. This is somewhat windowed down as > < potential wavelengths are discovered to be in use, but could be a > < significant burden for lightly loaded high channel count networks. > --- >> all wavelengths that could be used. The amount of information is redunced >> somewhat as potential wavelengths are discovered to be in use, but could >> be a significant burden for lightly loaded network with high channel >> counts. > 785c786 > < Figure 2 shows process flows for three main architectural > --- >> Figure 2 shows process flows for the three main architectural > 787c788 > < sufficient. Figure 3 shows process flows for two main architectural > --- >> sufficient. Figure 3 shows process flows for the two main architectural > 841c842 > < The advantages, requirements and suitability of these options are as > --- >> The advantages, requirements, and suitability of these options are as > 847c848 > < entity enabling highest potential optimality and efficiency in IA- > --- >> entity enabling the highest potential optimality and efficiency in IA- > 870c871 > < and RWA are very different and prone to specialization. > --- >> and RWA are very different and conducive to specialization. > 874c875 > < In this alternative a signaling protocol may be extended and > --- >> In this alternative, a signaling protocol may be extended and > 877c878 > < optimality of optimality as (a) or (b), it does not require > --- >> optimality as (a) or (b), it does not require > 903c904 > < The advantages, requirements and suitability of these detailed > --- >> The advantages, requirements, and suitability of these detailed > 909,911c910,912 > < computation entity enabling highest potential optimality and > < efficiency in IA-RWA; then has a separate entity performing detailed > < impairment validation. In the case of "black links" the authority > --- >> computation entity enabling the highest potential optimality and >> efficiency in IA-RWA while a separate entity performs detailed >> impairment validation. In the case of "black links", the authority > 925c926 > < high degree of potential optimality and efficiency in IA-RWA; then a > --- >> high degree of potential optimality and efficiency in IA-RWA while a > 963,966c964,967 > < As previously discussed most IA-RWA scenarios to a greater or lesser > < extent rely on a common impairment information model. A number of > < ITU-T recommendations cover detailed as well as approximate > < impairment characteristics of fibers and a variety of devices and > --- >> As previously discussed, most IA-RWA scenarios rely, to a greater or lesser >> extent, on a common impairment information model. A number of >> ITU-T recommendations cover detailed, as well as, approximate >> impairment characteristics of fibers, a variety of devices, and > 979,980c980,981 > < the networks composed of a single WDM line system vendor combined > < with OADMs and/or PXCs from potentially multiple other vendors, this > --- >> networks composed of a single WDM line system vendor combined >> with OADMs and/or PXCs from potentially multiple other vendors. This > 982,984c983,985 > < planed in the future that [G.680] will include networks incorporating > < line systems from multiple vendors as well as OADMs and/or PXCs from > < potentially multiple other vendors, this is known as situation 2 and > --- >> planned in the future that [G.680] will include networks incorporating >> line systems from multiple vendors, as well as, OADMs and/or PXCs kfrom >> potentially from multiple other vendors. This is known as situation 2 and > 990c991 > < distributed IV case one needs to standardize the accumulated > --- >> distributed IV case, one needs to standardize the accumulated > 996c997 > < and in what form for the protocol would need to be standardized for > --- >> and in what form would need to be standardized for protocol > 1005c1006 > < Different approaches to path/wavelength impairment validation gives > --- >> Different approaches to path/wavelength impairment validation give > 1008c1009 > < paths GMPLS routing may be used to distribute the impairment > --- >> paths, GMPLS routing may be used to distribute the impairment > 1012,1013c1013,1014 > < Depending on the computational alternative the routing protocol may > < need to advertise information necessary to impairment validation > --- >> Depending on the computational alternative, the routing protocol may >> need to advertise information necessary to the impairment validation > 1015,1018c1016,1019 > < high amount of data that need to be advertised. Such issue can be > < addressed separating data that need to be advertised rarely and data > < that need to be advertised more frequently or adopting other form of > < awareness solutions described in previous sections (e.g. centralized > --- >> volume of data that needs to be advertised. Such issue can be >> addressed by separating data that need to be advertised rarely from data >> that need to be advertised more frequently or adopting the other forms of >> awareness solutions as described in previous sections (e.g., centralized > 1029,1030c1030,1031 > < In term of approximated scenario (see Section 4.1.1.) the model > < defined by [G.680] will apply and routing protocol will need to > --- >> In term of approximated scenario (see Section 4.1.1.), the model >> defined by [G.680] will apply and the routing protocols will need to > 1033c1034 > < In the case of distributed-IV no new demands would be placed on the > --- >> In the case of distributed-IV, no new demands would be placed on the > 1054c1055 > < In section 4.3. a number of computation architectural alternatives > --- >> In section 4.3, a number of computation architectural alternatives > 1058,1059c1059,1060 > < cooperating PCEs, and the impacts on the PCEP protocol. This document > < is providing this evaluation to aid solutions work. The protocol > --- >> cooperating PCEs, and the impacts on the PCEP. This document >> provide this evaluation to aid solutions work. The protocol > 1085c1086 > < wavelength. If the computations could not complete successfully it > --- >> wavelength. If the computations could not complete successfully, it > 1087,1088c1088,1089 > < it is of interest to know if this was due to lack of wavelength > < availability or impairment considerations or both. The information > --- >> it is of interest to know if failure was due to lack of wavelength >> availability, impairment considerations, or both. The information > 1098c1099 > < functionality can be added to one of previously defined entities. > --- >> functionality could be added to one of previously defined entities. > 1100c1101 > < process coordinator. The roles, responsibilities and information > --- >> process coordinator. The roles, responsibilities, and information > 1107,1108c1108,1109 > < as needed during RWA computations. In particular it needs to know to > < use the Candidates-PCE to obtain potential set of routes and > --- >> as needed during RWA computations. In particular, it needs to know to >> use the Candidates-PCE to obtain the potential set of routes and > 1130c1131 > < computation. It needs not take into account current link wavelength > --- >> computation. It need not take into account current link wavelength > 1139,1140c1140,1141 > < initiating PCC. (Note: RWA-Coord PCE is also a PCC with respect to > < the IV-Candidate) > --- >> initiating PCC. Note that the RWA-Coord PCE is also a PCC with respect to >> the IV-Candidate. > 1174c1175 > < Coordinating-PCE and the IV-Candidates-PCE. > --- >> Coordinating-PCE, and the IV-Candidates-PCE. > 1176c1177 > < In step (a) the PCC requests a path meeting specified quality > --- >> In step (a), the PCC requests a path meeting specified quality > 1179,1181c1180,1182 > < associated parameters. In step (b) the RWA-Coordinating-PCE requests > < up to K candidate paths between nodes A and Z and associated > < acceptable wavelengths. In step (c) The IV-Candidates PCE returns > --- >> associated parameters. In step (b), the RWA-Coordinating-PCE requests >> up to K candidate paths and their associated acceptable wavelengths >> between nodes A and Z . In step (c), the IV-Candidates PCE returns > 1183c1184 > < paths and wavelengths as input (e.g. a constraint) to its RWA > --- >> paths and wavelengths as input (e.g., a constraint) to its RWA > 1191c1192 > < computation. In step (d) the RWA-Coordinating PCE returns the overall > --- >> computation. In step (d), the RWA-Coordinating PCE returns the overall > 1196c1197 > < Previously Figure 3 showed two cases where a separate detailed > --- >> Previously, Figure 3 showed two cases where a separate detailed > 1200c1201 > < the PCC it is possible to keep the interactions with this separate > --- >> the PCC, it is possible to keep the interactions with this separate > 1211c1212 > < will furnish signal characteristics, quality requirements, path > --- >> will furnish signal characteristics, quality requirements, path, > 1216c1217 > < actually be met. In the case where the impairment validation fails > --- >> actually be met. In the case where the impairment validation fails, > 1218c1219 > < quantify the failure, e.g., so a judgment can be made whether to > --- >> quantify the failure, e.g., so that a judgment can be made whether to > 1221c1222 > < Figure 6 shows a sequence diagram for the interactions for the > --- >> Figure 6 shows a sequence diagram for the interactions corresponding to the > 1223c1224 > < PCC, RWA-PCE (acting as coordinator), IV-Candidates-PCE and the IV- > --- >> PCC, RWA-PCE (acting as coordinator), IV-Candidates-PCE, and the IV- > 1226c1227 > < In step (a) the PCC requests a path meeting specified quality > --- >> In step (a), the PCC requests a path meeting specified quality > 1229,1231c1230,1232 > < associated parameters. In step (b) the RWA-Coordinating-PCE requests > < up to K candidate paths between nodes A and Z and associated > < acceptable wavelengths. In step (c) The IV-Candidates-PCE returns > --- >> associated parameters. In step (b), the RWA-Coordinating-PCE requests >> up to K candidate paths and their associated acceptable wavelengths >> between nodes A and Z. In step (c), the IV-Candidates-PCE returns > 1233,1234c1234,1235 > < paths and wavelengths as input (e.g. a constraint) to its RWA > < computation. In step (d) the RWA-Coordinating-PCE request a detailed > --- >> paths and wavelengths as input (e.g., a constraint) to its RWA >> computation. In step (d), the RWA-Coordinating-PCE requests a detailed > 1236,1237c1237,1238 > < (e) the IV-Detailed-PCE returns the results of the validation to the > < RWA-Coordinating-PCE. Finally in step (f)IA-RWA-Coordinating PCE > --- >> (e), the IV-Detailed-PCE returns the results of this validation to the >> RWA-Coordinating-PCE. Finally in step (f), the IA-RWA-Coordinating PCE > 1277c1278 > < Coordinating-PCE, IV-Candidates-PCE and IV-Detailed-PCE. > --- >> Coordinating-PCE, IV-Candidates-PCE, and IV-Detailed-PCE. > 1285c1286 > < architecture is put into use within a network it will by its nature > --- >> architecture is put into use within a network, it will by its nature > 1290c1291 > < work will address any issues on the use of impairment information. > --- >> work will address any issues on the protection of impairment information. > > Thanks, > Acee > >