Subject: [Pce] Questions on draft-ietf-pce-monitoring-09

From: Ramon Casellas <[email-masked]>
Date: Wed, 16 Jun 2010 09:50:45 +0200

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

---

From: Julien Meuric <[email-masked]>
Date: Wed, 16 Jun 2010 18:32:06 +0200

Hi Ramon.

This kind of review and feedback to the PCE mailing list (and to any WG 
list) is very welcome. Nevertheless, draft-ietf-pce-monitoring-09 has 
already run through the IESG and is nearly RFC 5886 (just a matter of days).

As a result, I have 2 requests:
- Ramon, people behind "we" and PCE'rs a large, reviews and comments are 
necessary to build and improve internet drafts: please, try to start 
sending them as soon as WG status is achieved (when the group owns the 
document) and before the end of last calls;
- authors, I think some answers from you would be useful to the community.

Thanks

Julien

Le 16/06/2010 09:50, Ramon Casellas a écrit :
> 4.2 states that "PCC-ID-REQ MUST be included (...)". There seems to be 
> a contradiction in Section 3.1
>
> * 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"
>
> 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 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?
> ============
>
> http://www.iana.org/assignments/pcep/pcep.xhtml which, although refer 
> to draft-ietf-pce-monitoring-09, are different
>
>

---

From: "Ramon Casellas" <[email-masked]>
Date: Wed, 16 Jun 2010 19:49:53 +0200 (CEST)

On Wed, June 16, 2010 6:32 pm, Julien Meuric wrote:

> This kind of review (...)
> already run through the IESG and is nearly RFC 5886 (...)

> document) and before the end of last calls;

Julien, all

I understand the issue; We are sorry for the late feedback (at this point
in the I.D. lifetime), but we got involved in active participation in IETF
PCE standardization work very recently. Given that in our first read of
the draft we spotted some issues, we reported them, hoping that it can
still be useful (to avoid these situations, we'll check the proper
procedures in order to report such issues once an I.D. has run through the
IESG or is already an RFC).

> - authors, I think some answers from you would be useful to the community.

For what is worth, let me point out a few more.  We apologize if
most(all?) of them have already been fixed in the to-be-released rfc:

* Typo: "in term of".

* The document mixes PCC_ID_REQ and PCC_REQ_ID, the PCE IANA file seems to
set on using PCC_REQ_ID

* Since the draft cites RFC5441 (objective function) it may be worth
mentioning that PCMonReq EBNF grammar mentions OF while PCReq one does
not. Likewise it does not appear in svec lists,

* In page 17, to avoid confusion, it is worth mentioning that the G bit
refers to the MONITORING object: "In the former case, the E bit of the
PROC-TIME object MUST be set.  The G bit MUST be cleared ..."
-

Thanks

R.