Skip to main content

A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths
draft-ietf-pce-brpc-09

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    pce mailing list <pce@ietf.org>, 
    pce chair <pce-chairs@tools.ietf.org>
Subject: Protocol Action: 'A Backward Recursive PCE-based 
         Computation (BRPC) Procedure To Compute Shortest Constrained 
         Inter-domain Traffic Engineering Label Switched Paths' to 
         Proposed Standard 

The IESG has approved the following document:

- 'A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute 
   Shortest Constrained Inter-domain Traffic Engineering Label Switched 
   Paths '
   <draft-ietf-pce-brpc-09.txt> as a Proposed Standard

This document is the product of the Path Computation Element Working 
Group. 

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pce-brpc-09.txt

Ballot Text

Technical Summary

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

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

   As reported in the PROTO writeup (see below), CWG consensus is 
   good. WG last call issues were limited to editorial and minor 
   functional nits.

   An IPR disclosure was made "somewhat late" in the process. The
   working group was given the opportunity to discuss the issue and
   consider whether to abandon the I-D and develop alternate mechanisms.
   However, despite the fact that viable alternate mechanisms have been 
   shown to be possible, no-one in the working group expressed any
   concerns or desire to make any changes.

Document Quality

   There is one known implementation of this document with several 
   known implementations in the pipe-line. Given how small the 
   protocol extensions defined in this document are, it is considered
   that proceeding on the basis of one implementation is OK.

Personnel

   Adrian Farrel is the document shepherd. Ross Callon is the
   responsible AD. 

   The document defines small protocol enhancements to PCEP (which is 
   on the same IESG agenda This I-D requests further allocations from
   the PCEP registry that IANA will create and manage. The same IANA
   expert should suffice for both documents. The IANA section of this 
   I-D uses the same language as the PCEP specification and, in
   particular, uses the same sub-registry names.

RFC Editor Note