Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering
RFC 4829

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: RFC Editor <rfc-editor@rfc-editor.org>
Cc: The IESG <iesg@ietf.org>, <iana@iana.org>, ietf-announce@ietf.org
Subject: Re: Informational RFC to be: 
         draft-deoliveira-diff-te-preemption-07.txt 

The IESG has no problem with the publication of 'LSP Preemption Policies 
for MPLS Traffic Engineering' 
<draft-deoliveira-diff-te-preemption-07.txt> as an Informational RFC. 

The IESG would also like the IRSG or RFC-Editor to review the comments in 
the datatracker 
(https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=10018&rfc_flag=0) 
related to this document and determine whether or not they merit 
incorporation into the document. Comments may exist in both the ballot 
and the comment log. 

The IESG contact person is Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-deoliveira-diff-te-preemption-07.txt


The process for such documents is described at http://www.rfc-editor.org/indsubs.html.

Thank you,

The IESG Secretary

Technical Summary
 
When the establishment of a higher priority Traffic Engineering Label
Switched Path requires the preemption of a set of lower priority TE LSPs,
a node has to make a local decision to select which TE LSPs will be
preempted.  The preempted LSPs are then rerouted by their respective
Head-end Label Switch Router. This document presents a flexible policy
that can be used to achieve a variety of objectives when LSPs are
preempted.  Simulation results are given and a comparison among several
different policies is also included.
 
Working Group Summary
 
This is an individual submission via the RFC editor. 
 
Protocol Quality
 
Ross Callon has reviewed this spec. The document, while an individual
submission, was referred to the CCAMP working group for progression. Using
the terms from section 3 of 3932, historically the reason was:

   5. The IESG thinks that this document extends an IETF protocol in a
      way that requires IETF review and should therefore not be
      published without IETF review and IESG approval.

At this point the document has been updated based on detailed comments by
the CCAMP co-chair, updated, and last called in the CCAMP working group.
Last call comments have been resolved. We believe that the status should
now be: 

   2. The IESG thinks that this work is related to IETF work done in WG
      CCAMP, but this does not prevent publishing.

Note to RFC Editor
 
We believe that having been successfully updated, and then
reviewed in CCAMP, the document is now ready to be published. Given that
this is still an individual submission, we believe that the proper note to
specify its status would be:

      This RFC is not a candidate for any level of Internet Standard.
      The IETF disclaims any knowledge of the fitness of this RFC for
      any purpose and in particular notes that the decision to publish
      is not based on IETF review for such things as security,
      congestion control, or inappropriate interaction with deployed
      protocols.  The RFC Editor has chosen to publish this document at
      its discretion.  Readers of this document should exercise caution
      in evaluating its value for implementation and deployment.  See
      RFC 3932 for more information.