[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