The MPLS WG Archive

["Adrian Farrel" <afarrel@movaz.com>]

Hi,

I still have a concern about this draft. My understanding of the existing RFCs
is that the soft-preemption behavior that you want is what is already specified.
There is, perhaps, an issue that the error code used for preemption is not well
specified in RFC3209.

I'd appreciate your thoughts.
Thanks,
Adrian

=========

In the Abstract you say
"Under present RSVP-TE signaling methods, LSPs are immediately displaced upon
preemption."

and in section 2, Motivation, you have
"Present MPLS RSVP-TE implementations only support a method of TE LSP
preemption which immediately tears down TE LSPs, disregarding the
preempted in-transit traffic, in an effort to make way for a higher
priority TE LSP if not enough bandwidth is available on the link to
accommodate the newly signaled high priority TE LSPs.  This process
nearly guarantees preempted traffic will be discarded, if only briefly,
until the RSVP Path Error message reaches and is processed by the
head-end (HE) and a new forwarding path can be established."

I disagree with your interpretation of RFC3209.

Section 4.7.3 has
" When preemption is supported, each preempted reservation triggers a
   TC_Preempt() upcall to local clients, passing a subcode that
   indicates the reason.  A ResvErr and/or PathErr with the code "Policy
   Control failure" SHOULD be sent toward the downstream receivers and
   upstream senders."

I'm inclined to agree with what George said in SF: this is a hole in RFC3209.
If we turn to RFC2205 for a definition of Policy Control Failure we find in
Appendix B...
"   o    Error Code = 02: Policy Control failure

        Reservation or path message has been rejected for administrative
        reasons, for example, required credentials not submitted,
        insufficient quota or balance, or administrative preemption.
        This Error Code may appear in a PathErr or ResvErr message.

        Contents of the Error Value field are to be determined in the
        future."

Nowhere here do I see anything that says that the LSP is torn down, but rather
that the traffic becomes best effort (which is what you want in your draft).
Perhaps the main issue is that nearly all the references to PathErr in RFC3209
relate to errors during the LSP setup procedure. But surely PathErr messages
that happen after the LSP has been established inherit their behavior from
RFC2205 if there is nothing else described in RFC3209.

Section 3.5 or RFC2205 says
"     There are two RSVP error messages, ResvErr and PathErr.  PathErr
      messages are very simple; they are simply sent upstream to the
      sender that created the error, and they do not change path state
      in the nodes though which they pass.  There are only a few
      possible causes of path errors."


Note that there is already a suitable error code defined in RFC 2205.

"  o    Error Code = 12: Service preempted

        The service request defined by the STYLE object and the flow
        descriptor has been administratively preempted.

        For this Error Code, the 16 bits of the Error Value field are:
           ssur cccc cccc cccc

        Here the high-order bits ssur are as defined under Error Code
        01.  The globally-defined sub-codes that may appear in the low-
        order 12 bits when ssur = 0000 are to be defined in the future."

This tends to imply that the Error Code is only available for use on a ResvErr
(since that is where the flow descriptor is).

Alternatively, you could either define a new Error Value for the "Policy Control
failure" Error Code, or perhaps you would rather move the condition to the
"Notify" Error Code.  For consistency, one might assign the new Error Value
using the ssur cccc cccc cccc format, setting the u-bit to 1 to show that this
represents a state update that should be passed onwards, although RFC3209
doesn't bother with the u-bit and says
"   For the Notify Error Code, the 16 bits of the Error Value field are:
         ss00 cccc cccc cccc"