[Pce] Questions on draft-ietf-pce-monitoring-09
Ramon Casellas <ramon.casellas@cttc.es> Wed, 16 June 2010 07:48 UTC
Return-Path: <ramon.casellas@cttc.es>
X-Original-To: pce@core3.amsl.com
Delivered-To: pce@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD273A6AD8 for <pce@core3.amsl.com>; Wed, 16 Jun 2010 00:48:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.601
X-Spam-Level:
X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_83=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifhPe4GYCowc for <pce@core3.amsl.com>; Wed, 16 Jun 2010 00:48:17 -0700 (PDT)
Received: from scorpius.cttc.es (scorpius.cttc.es [84.88.62.197]) by core3.amsl.com (Postfix) with ESMTP id 6FF0D3A6AD3 for <pce@ietf.org>; Wed, 16 Jun 2010 00:48:15 -0700 (PDT)
Received: from castor (postfix@castor.cttc.es [84.88.62.196]) by scorpius.cttc.es (8.13.8/8.13.5) with ESMTP id o5G7lpNS008155 for <pce@ietf.org>; Wed, 16 Jun 2010 09:47:51 +0200
Received: from [84.88.61.50] (pcrcasellas.cttc.es [84.88.61.50]) by castor (Postfix) with ESMTP id 0D96E2FC248; Wed, 16 Jun 2010 09:47:31 +0200 (CEST)
Message-ID: <4C188255.8020101@cttc.es>
Date: Wed, 16 Jun 2010 09:50:45 +0200
From: Ramon Casellas <ramon.casellas@cttc.es>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: pce@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (castor); Wed, 16 Jun 2010 09:47:32 +0200 (CEST)
X-Scanned-By: MIMEDefang 2.57 on 84.88.62.197
Subject: [Pce] Questions on draft-ietf-pce-monitoring-09
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pce>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jun 2010 07:48:18 -0000
Dear draft authors, all, We have started reading the I.-D. draft-ietf-pce-monitoring-09, and we have some comments / questions as detailed below. Clarifications and comments are much welcome :) Questions ============ * In Section 3.1 it is stated that "there is one mandatory object that MUST be included (...) Other objects are optional"; however, the EBNF notation suggests that PCC-ID-REQ is mandatory (pag 7). Also, Section 4.2 states that "PCC-ID-REQ MUST be included (...)". There seems to be a contradiction in Section 3.1 * Similar questions apply for PCReq (pag 8), PCMonRep(pag 10), PCRep, regarding the same PCC-ID-REQ object. * Related to these, In section 4.2. it is stated "The PCC-ID-REQ MUST be inserted within a PCReq or a PCMonReq message to (...)". We interpret this as "The PCC-ID-REQ MUST be inserted within a PCReq message with monitoring data requested (i.e. after the MONITORING) object" * If PCC-ID-REQ is mandatory, souldn't an Error 6 : Mandatory Object missing / 5: PCC-ID-REQ Object missing be added"? along the lines of "If a PCE receives a PCMonReq with the PCC-ID-REQ missing or a PCReq with a MONITORING object but without a PCC-ID-REQ missing it MUST generate aPCEPError 6,5? MONITORING * The draft specifies the procedure when the flags, are set. For the sake of completeness, if flags L, P, C are *not* set in the MONITORING object, what would be the recommended action? the PCE should/should not/may/must not/ include the correspondong PCE_ID, PROC_TIME and OVERLOAD metrics? PROC-TIME * In PROC-TIME object, the variance is said to be indicated in milliseconds. Shouldn't it be in squared milliseconds ? (alternatively one should use the standard deviation) * From our understanding, the PROC_TIME object is supposed to include the path computation time. What is the rationale to not include also the queueing (waiting) time, which specially on overloaded situations, may be significant? On the one hand, the total service request seen by the PCC will also include queueing time (and of course, network latency, etc.), but on the other hand, the text seems to hint that to estimate / to compute processing time the PCE may / must perform the actual path computation, but the queueing time is not mentioned. Since one may assume that permanent regime the PCE will have a queue with (optionally) some priority management, and that we can define a mean number of "customers" (opt. per priority) and mean waiting time, we understand that the total processing time would required either add an estimated "mean waiting time", or, for the actual computation, the request should be tagged at arrival before enqueieng it. OVERLOAD * In Section 4.5 it is said that OVERLOAD MUST be present if C bit (...) is set *and* the PCE is experiencing a congested state. One could assume that the overload may be estimated by the product "number of queued requests at the time the MONITORING object is processed" * "average processing time" or * "max processing time" (worst case), (in seconds). What is the procedure if the PCE is *not* congested (e.g. no backlog), must it return 0? (In other words, the confusing part is "and the PCE is experiencing a congested state" as a condition to insert the OVERLOAD object. Errata? ============ * Section 4.2 mentions object PCE-ID-REQ, (the format of the PCE-ID-REQ... ) typo. It should say PCC-ID-REQ. * Section 4.3 typo "specifyt". * Section 4.5 "This field indicates in the amount of time in seconds" * Section 4.5 refers to the OVERLOAD object but in pag 19. the old? CONGESTION name is used: "the format of the CONGESTION object" Thanks for reading, Ramon ps: We are using object classes from http://www.iana.org/assignments/pcep/pcep.xhtml which, although refer to draft-ietf-pce-monitoring-09, are different -- Ramon Casellas, Ph.D. Research Associate - Optical Networking Area -- http://wikiona.cttc.es CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4 Av. Carl Friedrich Gauss 7 08860 Castelldefels (Barcelona) - Spain Tel.: +34 93 645 29 16 -- Fax. +34 93 645 29 01
- [Pce] Questions on draft-ietf-pce-monitoring-09 Ramon Casellas
- Re: [Pce] Questions on draft-ietf-pce-monitoring-… Julien Meuric
- Re: [Pce] Questions on draft-ietf-pce-monitoring-… Ramon Casellas