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. --- _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
