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

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 19 Apr 2005 07:31:25 -0500

Hi Dimitri,

Thanks for your comments.

> 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?

Your rewording is clearer, thanks.

> 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?

We think it's in scope.

> 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

Agreed.

Thanks,
Jerry

> hope this helps,
> - dimitri.

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