[Pce] FW: I-D Action:draft-ietf-pce-brpc-08.txt

[JP Vasseur <[e-mail]>]

Hi,

This new revision takes into account the comments received during Last Call:
1) Editorial changes, clarifications, updated references, ...

2) Text added: 
    The BRPC procedure relies on communication between cooperating PCEs.
    In particular, the PCC sends a PCReq to a PCE in its domain.  The
    request is forwarded between PCEs, domain-by-domain until the PCE
    responsible for the domain containing the LSP destination is reached.
    The PCE in the destination domain creates a tree of potential paths
    to the destination (the Virtual Shortest Path Tree - VSPT) and passes
    this back to the previous PCE in a PCRep.  Each PCE in turn adds to
    the VSPT and passes it back until the PCE in the source domain uses
    the VSPT to select an end-to-end path that it sends to the PCC.

Main changes are:

3) Section 4
OLD
4.  BRPC Procedure

   The BRPC procedure is a Multiple-PCE path computation technique as
   described in [RFC4655].  A possible model consists of hosting the PCE
   function on boundary nodes (e.g., ABR or ASBR) but this is not
   mandated by the BRPC procedure.

   The BRPC procedure does not make any assumption with regards to the
   nature of the inter-domain TE LSP that could be contiguous, nested or
   stitched.

   Furthermore, no assumption is made on the actual path computation
   algorithm in use by a PCE (e.g., it can be any variant of CSPF or an
   algorithm based on linear-programming to solve multi-constraints
   optimization problems).

NEW:
4.  BRPC Procedure

   The BRPC procedure is a Multiple-PCE path computation technique as
   described in [RFC4655].  A possible model consists of hosting the PCE
   function on boundary nodes (e.g., ABR or ASBR) but this is not
   mandated by the BRPC procedure.

   The BRPC procedure relies on communication between cooperating PCEs.
   In particular, the PCC sends a PCReq to a PCE in its domain.  The
   request is forwarded between PCEs, domain-by-domain until the PCE
   responsible for the domain containing the LSP destination is reached.
   The PCE in the destination domain creates a tree of potential paths
   to the destination (the Virtual Shortest Path Tree - VSPT) and passes
   this back to the previous PCE in a PCRep.  Each PCE in turn adds to
   the VSPT and passes it back until the PCE in the source domain uses
   the VSPT to select an end-to-end path that it sends to the PCC.

   The BRPC procedure does not make any assumption with regards to the
   nature of the inter-domain TE LSP that could be contiguous, nested or
   stitched.

   Furthermore, no assumption is made on the actual path computation
   algorithm in use by a PCE (e.g., it can be any variant of CSPF or an
   algorithm based on linear-programming to solve multi-constraint
   optimization problems).

3) Section 9

OLD:
9.  BRPC procedure completion failure

   If the BRPC procedure cannot be completed because a PCE along the
   domain path does not support the procedure, a PCErr message MUST be
   returned to the upstream PCE with a Error-Type "BRPC procedure
   completion failure".  The PCErr message MUST be relayed to the
   requesting PCC.

   PCEP-ERROR objects are used to report a PCEP protocol error and are
   characterized by an Error-Type which specifies the type of error and
   an Error-value that provides additional information about the error
   type.  Both the Error-Type and the Error-Value are managed by IANA.
   A new Error-Type is defined that relates to the BRPC procedure.

 Error-type          Meaning
     13              BRPC procedure completion failure
                      Error-value
                         1: BRPC procedure not supported by one or more PCEs
                            along the domain path

NEW:
9.  BRPC Procedure Completion Failure

   If the BRPC procedure cannot be completed because a PCE along the
   domain does not recognize the procedure (VSPT flag of the RP object),
   as stated in [I-D.ietf-pce-pcep], the PCE sends a PCErr message to
   the upstream PCE with an Error-Type=4 (not supported object), Error-
   value-4 (Unsupported paramater).  The PCE may include the parent
   object (RP object) up to and including (but no further than) the
   unknown or unsupported parameter.  In this case where the unknown or
   unsupported parameter is a bit flag (VSPT flag), the included RP
   object should contain the whole bit flag field with all bits after
   the parameter at issue set to zero.  The corresponding path
   computation request is then cancelled by the PCE without further
   notification.

   If the BRPC procedure cannot be completed because a PCE along the
   domain path recognises but does not support the procedure, it MUST
   return a PCErr message to the upstream PCE with an Error-Type "BRPC
   procedure completion failure".

   The PCErr message MUST be relayed to the requesting PCC.

   PCEP-ERROR objects are used to report a PCEP protocol error and are
   characterized by an Error-Type which specifies the type of error and
   an Error-value that provides additional information about the error
   type.  Both the Error-Type and the Error-Value are managed by IANA.
   A new Error-Type is defined that relates to the BRPC procedure.

  Error-type       Meaning
      13           BRPC procedure completion failure
                   Error-value
                     1: BRPC procedure not supported by one or more PCEs
                        along the domain path


4) Section 4.14 (to be in-line with the definition of "Verifying Correct
Operation" adopted in PCEP).

OLD:
14.4.  Verifying Correct Operation

   Verifying the correct operation of BRPC can be done by looking at the
   TEDs related to the various domains traversed by a TE LSP at the time
   the BRPC procedure was invoked and verify that the path computed by
   the BRPC procedure is the expected optimal inter-domain constrained
   path (the path that would be obtained in the absence of multiple
   domains).



NEW:
14.4.  Verifying Correct Operation

   Verifying the correct operation of BRPC can be performed by
   monitoring a set of parameters.  A BRPC implementation SHOULD provide
   the following parameters:

   o Number of successful BRPC Procedure completions on a per PCE peer
   basis,

   o Number of BRPC procedure completion failures because the VSPT flag
   was not recognized (on a per PCE peer basis),

   o Number of BRPC procedure completetion failures because the BRPC
   procedure was not supported (on a per PCE peer basis),


Thanks.

JP.

------ Forwarded Message
> From: <[e-mail]>
> Reply-To: <[e-mail]>
> Date: Wed,  2 Apr 2008 14:00:01 -0700 (PDT)
> To: <[e-mail]>
> Cc: <[e-mail]>
> Subject: I-D Action:draft-ietf-pce-brpc-08.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Path Computation Element Working Group of the
> IETF.
> 
> 
> Title           : draft-ietf-pce-brpc-08.txt
> Author(s)       : J. Vasseur, et al.
> Filename        : draft-ietf-pce-brpc-08.txt
> Pages           : 19
> Date            : 2008-04-02
> 
> The ability to compute shortest constrained Traffic Engineering Label
> Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
> Generalized MPLS (GMPLS) networks across multiple domains (where a
> domain is a collection of network elements within a common sphere of
> address management or path computational responsibility such as an
> IGP area or an Autonomous Systems) has been identified as a key
> requirement.  This document specifies a procedure relying on the use
> of multiple Path Computation Elements (PCEs) to compute such inter-
> domain shortest constrained paths across a predetermined sequence of
> domains, using a backward recursive path computation technique.  This
> technique preserves confidentiality across domains, which is
> sometimes required when domains are managed by different Service
> Providers.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-08.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[e-mail]>
> 
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

------ End of Forwarded Message

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