Subject: [Pce] PCE Charter Update

From: JP Vasseur <[email-masked]>
Date: Sat, 10 Jul 2010 10:10:42 +0200

Dear all,

We have updated our charter milestone with two new WG items that have  
been completed (both on P2MP)" http://datatracker.ietf.org/wg/pce/charter/
Julien and I are working on the PCE agenda, we'll have a slot to  
discuss the PCE charter at the next PCE WG meeting in Maastricht.

Thanks.

JP.

---

From: "POUYLLAU, HELIA (HELIA)" <[email-masked]>
Date: Mon, 12 Jul 2010 17:35:43 +0200

Hi all,

We have submitted an updated version of draft http://www.ietf.org/id/draft-pouyllau-pce-enhanced-errors-02.txt

The major update is - as mentioned during IETF 77 meeting - a new section describing some potential scenarios of usages of the error and notification types specified by the draft. 

Before detailing further these scenarios, we would like to have feedback from the mailing-list. Obviously, feedback on other sections is also welcomed.

Best regards
Hélia Pouyllau

---

From: Attila Takacs <[email-masked]>
Date: Thu, 29 Jul 2010 14:20:36 +0200

Hi Helia,

As far as I understood there are two main points in the id 1) clarifying error and notification usage and 2) allowing remote (non direct peer PCEs) to send errors/notifications to the originating PCC.

I have no feelings about 1), it might be needed if the description in 5440 is indeed unclear or if additional details on processing would clarify procedures of 5440. 

On the other hand, 2) is a bit confusing to me. If I remember correctly a PCC will not know about other PCEs involved in the path computation except its direct peer PCE. So I do not see a reason why a remote PCE should be able to force PCC's peer PCE to forward any error/notification information. To me its seems that error/notification propagation is a local matter of the direct peer PCE since that is handling the request and it is the only PCE that the PCC has a relation with for a particular request. Do I miss something?

Thanks,
Attila 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of POUYLLAU, HELIA (HELIA)
> Sent: Monday, July 12, 2010 5:36 PM
> To: [email-masked]
> Subject: [Pce] I-D Update draft-pouyllau-pce-enhanced-errors-02
> 
> 
> Hi all,
> 
> We have submitted an updated version of draft 
> http://www.ietf.org/id/draft-pouyllau-pce-enhanced-errors-02.txt
> 
> The major update is - as mentioned during IETF 77 meeting - a 
> new section describing some potential scenarios of usages of 
> the error and notification types specified by the draft. 
> 
> Before detailing further these scenarios, we would like to 
> have feedback from the mailing-list. Obviously, feedback on 
> other sections is also welcomed.
> 
> Best regards
> Hélia Pouyllau
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: Meral Shirazipour <[email-masked]>
Date: Thu, 29 Jul 2010 13:58:12 -0400

Hi,

  I have a few comments about errors and notifications specific to a given (or a
set of) path request(s) :

  I believe any error, related to a specific path request that caused the
failure in finding a path should be returned in the PCRep message's NO-PATH
object, and not as a separate PCErr.
Moreover, any information that should be conveyed but that did not cause the
failure of a request should be sent as a PCNtf message and not a PCErr message.

I explain:

First in section 5.3.  Error-type 18 Usage:
--------------------------------------------

the example given is an IRO which can not be satisfied by the next PCE. As per
RFC5440 section 7.5, such information may already be carried in the PCRep's
NO-PATH object:

Recall RFC5440 section 7.5:"the NO-PATH object MAY contain an optional
NO-PATH-VECTOR TLV defined below and used to provide more information on the
reasons that led to a negative reply."

Then in section 5.4 Error-type 19 Usage:
--------------------------------------------

the example is "the next PCE in the path computation chain is no more active,
and thus the PCC is notified."

I believe in this case too as per RFC5440, the NO-PATH object should carry the
information.

**Moreover, I also think this specific failure information should reach the PCC
only IF the PCC specifically requested the failed PCE to be in the PCE
sequence.
Now that begs the question of needing some sort of policy to control the reach
of the Error and Notification messages.**

The rest of the examples describe cases where a path is found but with minor
modifications to the constraints. For these, the draft's proposition is correct
since RFC5440 only allows information to be added to the PCRep message IF it
caused the failure of the request (i.e. NO-PATH):
-LSPA (LSP Attributes) object can be included in the PCRep message only if it
caused an unsuccessful path computation,(recall the LSPA object is used to
indicate the set of constraints that could not be satisfied)
-NO-PATH Object, NO-PATH-VECTOR TLV applies only to an unsuccessful path
computation

Thus, the draft is completely correct in conveying this type of information in a
separate message since the information DID not cause the failure of the request.
However, I suggest conveying such information in a notification message (PCNtf)
and not an Error message (PCErr) as proposed.

I would thus reconsider the examples in:

5.1.  Error-type 16 Usage
---------------------------

"..a PCE receiving a request does not understand a
   parameter value...This error is not critical.."

and

5.2.  Error-type 17 Usage
-------------------------

"..a parameter is not supported by one of the PCE
...this error is not critical"

and send the information in a notification messages (PCNtf).

Regards,
Meral

PS: some more comments are on the way

Quoting "POUYLLAU, HELIA (HELIA)" <[email-masked]>:

> The major update is - as mentioned during IETF 77 meeting - a new section
> describing some potential scenarios of usages of the error and notification
> types specified by the draft.
>
> Before detailing further these scenarios, we would like to have feedback from
> the mailing-list. Obviously, feedback on other sections is also welcomed.
>
> Best regards
> Hélia Pouyllau
>