Subject: [Pce] comments on draft-ash-pce-comm-protocol-gen-reqs-00.txt

From: dimitri papadimitriou <[email-masked]>
Date: Tue, 19 Apr 2005 13:58:14 +0200

all, some comments on the architecture document:

section 5.

"an error is returned together with as much
information as possible about the reasons for the failure, and
potentially advice about which constraints might be relaxed to be more
likely to achieve a positive result."

-> what "as much" means in the present context - wouldn't be advisable
to say enough information such that the appropriate decision can be made
by the PCC to know whether it has to relax constraints or query another
PCE ?

section 6.1.1

"The protocol MUST be capable of returning any explicit path that would
be acceptable for use in RSVP-TE for MPLS and GMPLS LSPs when suitably
encoded in an Explicit Route Object."

-> this is definitelly a possible way to encode such information, but is
it within the scope of the present document to enforce this ?

section 6.3.3

"The communication protocol SHOULD allow a stateful PCE to resynchronize
and recover states (e.g., LSP status, paths, etc.) after a restart."

-> this in an interesting statement because it proofs that robustness is
achieved from distribution (and not centralized state maintenance) ... 
anyway there is a strict need to define the notion a path computation 
state (which is not identical to an LSP status) before starting 
discussing the needs to allow for such capability

hope this helps,
- dimitri.

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 25 Apr 2005 16:41:07 +0100

Hi Dimitri,

> it within the scope of the present document to enforce this ?

This is not how I read the text.
I assumed they meant that the information supplied by the PCE should have
everything that you need to construct an ERO.

That is, it could be re-written as...

   The protocol MUST be capable of returning any explicit path that would
   be acceptable for use for MPLS and GMPLS LSPs once converted to
   an Explicit ROute Object for use in RSVP-TE signaling.

Cheers,
Adrian