[mpls] Protocol Action: 'MPLS Traffic Engineering Soft Preemption' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'MPLS Traffic Engineering Soft Preemption '
   <draft-ietf-mpls-soft-preemption-18.txt> as a Proposed Standard


This document is the product of the Multiprotocol Label Switching Working Group. 

The IESG contact persons are Adrian Farrel and Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-soft-preemption-18.txt

Technical Summary

  This document specifies MPLS-TE soft preemption through a number
  of protocol extensions. The goal is to reduce/eliminate traffic 
  disruption on preempted TE LSPs. MPLS RSVP-TE is defined up to this
  point supported only immediate TE LSP displacement upon preemption.  
  This document defines a reroute request notification which more 
  gracefully mitigates the reroute process of the preempted TE LSP.
  This may lead to a sitution of under-provioning while soft 
  preemption is executed. For this reason, the feature is primarily
  of interest in MPLS enabled IP networks with Differentiated 
  Services and Traffic Engineering capabilities.

Working Group Summary

  This document has been around for along time with a number of 
  contentious issues. There have been several attempts to resolve the 
  issues that gave rise to the creation of draft-ietf-mpls-3209-patherr 
  and draft-ietf-mpls-gmpls-lsp-reroute to cover all issues. 

  There were several major issues:

  - There were poor base definitions of the "normal" behavior. This meant

    that there was debate about whether these extensions were needed.

  - There was no clear definition of sot and hard preemption. This led
    to debate about exactly what was required and what was already 
    available.

  - Existing specification for MPLS and GMPLS were not totally in synch.
    This led to debate over which of the potential ways forward that
    already existed was correct.

  After lengthy debate on the mailing list and in face-to-face meetings,
  this document was revised and the other two documents were produced. 
  This led to WG consensus.

Document Quality

  There are no known implementations of this document, but given the
  strength of support from one vendor and two carriers we may expect
  implementation soon.

Personnel

  Loa Andersson is the Document Shepherd.
  Adrian Farrel is the Responsible Area Director.

RFC Editor Note

---
Section 1 para 1
OLD
   Understandably desirable features like ingress (Label Edge Router)
   LER automated (Traffic Engineering (TE) reservation adjustments are
   less palatable when preemption is intrusive and high network
   stability levels are a concern.
NEW
   Understandably, desirable features like ingress Label Edge Router
   (LER) automated Traffic Engineering (TE) reservation adjustments are
   less palatable when preemption is intrusive and high network
   stability levels are a concern.

---
Section 10
OLD
   This document does not introduce new security issues.  The security
   considerations pertaining to the original RSVP protocol [RFC3209]
   remain relevant.
NEW
   This document does not introduce new security issues.  The security
   considerations pertaining to the original RSVP protocol [RFC3209]
   remain relevant. Further details about MPLS security considerations
   can be found in [I-D.ietf-mpls-mpls-and-gmpls-security].

   As noted in Section 6.1, soft preemption may result in temporary link
   under provisioning condition while the soft preempted TE LSPs are
   rerouted by their respective head-end LSRs. Although this is a less
   serious condition than false hard preemption, and despite the
   mitigation procedures described in Section 6.1, network operators
   should be aware of the risk to their network should the soft
   preemption processes be subverted, and should apply the relevant MPLS
   control plane security techniques to protect against attacks.
---
Section 13.2
ADD
   [I-D.ietf-mpls-mpls-and-gmpls-security] Fang, L. Ed., "Security
              Framework for MPLS and GMPLS Networks", draft-ietf-mpls-
              mpls-and-gmpls-security-framework-06.txt, work in
              progress.
---