Subject: Re: [Pce] PCE Monitoring : wrong version last called

From: "Fabien Verhaeghe" <[email-masked]>
Date: Mon, 19 Jan 2009 13:55:30 +0100

Hi JP,

Thanks for the update.
Everything seems fine to me except 2 minor comments.
See inline

>> That is my fault :-(
>> 
>> The I-D is at revision -03
>> 
>> http://www.ietf.org/internet-drafts/draft-ietf-pce-monitoring-03.txt
>> 
>> You still have until Monday next week if you want to make comments.
>> 
>> As my punishment, I have gone through Fabien's email to check which of 
>> his coments still apply...
>> 
>> 
>> Below my comments on monitoring draft:
>> 
>> Section 3.1:
>> 
>> Example 3: The request must also contain a MONITORING object.
>> 
>> Issue stands.
>> 
> That was "in addition to" but the text had been clarified, thanks.
> 
> 

Ok

>> Section 3.2:
>> 
>> The format of a PCReq message is as follows:
>> 
>> Must be
>> 
>> The format of a PCMonRep message is as follows:
>> 
>> Issue stands
> 
> Fixed.
> 

Format of a PCMonReq (out of band request):

Must be replaced by

Format of a PCMonRep (out of band request):

>> 
>> Section 4.1:
>> 
>> Seems the first sentence is repeated twice.
>> 
>> Fixed in revision -03
>> 
>> 
>> Besides it is said that the Monitoring object MAY be included in
>> PCReq and PCRep so I think it would be good to add the enhanced
>> PCReq and PCRep BNF description.
>> 
>> Issue stands
>> 
> Added.
> 

Ok

>> Also in 4.1
>> s/PCEReq/PCReq/
> Fixed.

Ok

>> 
>>General comment:
>> 
>> The in-band monitoring request is not fully clear to me.
>> 
> 
> You are right that this is not clearly explained in the current text.
> 
>>
>> If there are several path computation requests in the PCReq
>> which one is targeting?
>> i.e. Must the PCE return the processing time for each request seperatly
>> or a single processing time for all requests?
> 
> We could decide to have one MONITORING object per request in the bundle
> case
> but this does
> introduce some complexity and is not likely to be that useful. I'd rather
> propose to keep the current
> mode with one MONITORING object per PCMonReq or PCReq message. When
> present
> the
> monitoring request applies to all requests of the bundle. Text added in
> section 3.2.
> 

Seems good to me except maybe I would rather put the text in section 3.1
that deals with PCReq.

> "
> As pointed out in [PCEP] we can have several situations:
>  o   Bundle of a set of independent and non-synchronized path
>       computation requests,
> 
>    o  Bundle of a set of independent and synchronized path computation
>        requests (SVEC object defined below required),
> 
>    o  Bundle of a set of dependent and synchronized path computation
>        requests (SVEC object defined below required).
> 
> In the case of a bundle of a set of request, the MONITORING object SHOULD
> only be present in the
> first PCReq or PCMonReq message and the monitoring request applies to all
> the request of the bundle,
> even in the case of dependent and/or synchronized requests sent using more
> than one PCReq or
> PCMonReq message.
> 
> 
> 
> 
> 
>> In first case what happens if there is an SVEC object and Path Requests
>> are spread in multiple PCRep messages. Must the Monitoring object be
>> repeated?
> 
> 
> See above.
> 

Ok

> 
>> If a PCRep contains a Monitoring object, is it possible that
>> this PCRep contains Path replies not related to the Monitoring
>> request?
> 
> Yes because in the BNF, the <metric-pce-list> is per in the <response>
> 

Ok

> Thanks for the comments.
> 
> Cheers,
> 
> JP.
> 
> 
> 
> 
> Issue stands.
> 
> Happy New Year
> 
> Adrian
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: JP Vasseur <[email-masked]>
Date: Tue, 20 Jan 2009 08:13:34 +0100

Hi Fabien,

> Everything seems fine to me except 2 minor comments.

Thanks , see below,

Fixed.

> Seems good to me except maybe I would rather put the text in section  

Indeed.

>> Yes because in the BNF, the <metric-pce-list> is per in the  

Thanks.

JP.