The MPLS WG Archive

[Ina Minei <ina@juniper.net>]

	Hello Adrian,

	As far as I can see, the two issues raised are:
1) the need for the soft-preemption draft
2) the use of the rro mechanism rather than a path error for the
notifications.

	I will address them separately below.

1) The need for soft-preemption
	I agree that 3209 doesn't explicitly specify that the
preempted lsp should be torn down. However, rfc 2702, when discussing the
preemption attribute makes it clear that preemption is there to accomodate
the case where there are not enough resources to share, and overbooking is
not mentioned. Thinking of the goal that preemption is trying to achieve,
it seems reasonable that immediate teardown would be performed.
	In any case, I think a specification is necessary for
soft-preemption. I also believe there is value in allowing the user to
specify whether soft preemption is desired or not on a per-lsp basis and
how long the overbooking may be maintained.

2) The use of rro vs path error
	The original proposal for this draft was to use a path-error
message (and allocate a new notify-error subcode), just like you propose.
A few private and  public discussions on this topic took place. There are
pros/cons to both approaches, and the authors decided to pick the rro
solution.

			Ina



On Mon, 19 May 2003, Adrian Farrel wrote:

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