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