Subject: [Pce] Draft minutes PCE WG Meeting IETF-69

From: JP Vasseur <[email-masked]>
Date: Thu, 9 Aug 2007 14:02:59 -0400

Hi,

The draft minutes have been posted: http://www3.ietf.org/proceedings/ 
07jul/minutes/pce.txt

Please comments your comments if any by August 24.

JP.

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

---

From: JP Vasseur <[email-masked]>
Date: Thu, 9 Aug 2007 14:11:01 -0400

> Please "send" your comments if any by August 24.

Begin forwarded message:

> From: JP Vasseur <[email-masked]>
> Date: August 9, 2007 2:02:59 PM EDT
> To: [email-masked]
> Subject: [Pce] Draft minutes PCE WG Meeting IETF-69
>
> Hi,
>
> The draft minutes have been posted: http://www3.ietf.org/ 
> proceedings/07jul/minutes/pce.txt
>

---

From: "Fabien VERHAEGHE" <[email-masked]>
Date: Fri, 10 Aug 2007 14:25:54 +0200

Hello all,

I have a little comment/suggestion on PCEP regarding the request Id.

In section 7.3.1 states that

"The Request-ID-number value combined with the source IP address of the PCC
and the PCE address uniquely 

identify the path computation request context".

I agree with that, however there may be 2 requests with same request Id
exchanged on the same session in 

the case of session between 2 PCEs. 

One Path Request being sent by PCE#1 to PCE#2 and the other one by PCE#2 to
PCE#1.

I don't think there is any problem with that but I am a little concerned
about potential misinterpretation especially

in PCErr and PCNotif message.

If a PCNtf/PCErr message contains an RP object, nothing indicates if it is
related to the Request from PCE#1 to PCE#2

or the one from PCE#2 to PCE#1, except the notification/error type and
value.

I guess this is why for instance for the "Pending Request cancelled"
notification there are 2 values. One for PCC and

one for the PCE.

One of the problem, from an implementation perspective, is that we must
first ready the Notification type/value in order to retrieve

the correct PathRequest.

Another problem is if an implementation does not recognize a given Error
type/value, then it can't tell for sure which PathRequest it

is related to.

So it seems to me it would be more consistent to add a bit in the RP object
(in the flag field) to indicate the

"direction" of the PathRequest.

For instance if the bit is set the Message that carry the RP object is
related to the request sent by the destination of the message.

Hence, an RP object would actually uniquely indentifies a PathRequest.

Regards

Fabien Verhaeghe