Subject: draft-ietf-mpls-soft-preemption-00

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 19 May 2003 20:13:40 -0400

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"

---

From: Ina Minei <[email-masked]>
Date: Thu, 22 May 2003 10:49:47 -0700 (PDT)

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

---

From: "Ina Minei" <[email-masked]>
Date: Thu, 22 May 2003 10:49:47 -0700 (PDT)

Hello Adrian,

			Ina

---

From: "Ina Minei" <[email-masked]>
Date: Thu, 22 May 2003 10:49:47 -0700 (PDT)

Hello Adrian,

			Ina

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 22 May 2003 15:23:13 -0400

Hi Ina,

Thanks for engaging.

> I will address them separately below.

That's fine.
I am trying to discuss only issue 1).
I have strong feelings about the use of the RRO for this proposal, but I don't
want to get into them at this stage.

> it seems reasonable that immediate teardown would be performed.

I think this depends radically on the network type. In an optical network, for
example, it is wholly reasonable to say that preemption of a resource at a
particular node breaks the LSP. That is, if I take the laser and use it for
something else, then traffic on the old LSP stops flowing. This also probably
causes alarms.

Depending on the way that this intercepted resource is used, the downstream LSP
may need to be torn (to prevent data being sent to the wrong place).
If the LSP is bidirectional, the upstream LSP may also need to be torn.
There is a facility for both of these options (PathTear and PathErr with state
removal).

On the other hand in some optical networks, it will be highly desirable to avoid
resource churn by leaving the most of the LPS in place and treating the
preemption just like an alarm or a resource failure. The ingress (or some other
repair point) can use make before break to repair around the error without
deprovisioning and reprovisioning at all of the other nodes.

Now, in a packet network, we can add to this list the facility for
over-provisioniing and handling traffic as best effort.  In these cases the most
that happens is that the LSP is degraded. The level of this degradation is on a
scale from total (as in the optical network) to none, when the traffic on other
resource users is low. If there is ever the cahnce of passing traffic, it seems
best to do so. This will show less impact for the customer.

> specify whether soft preemption is desired or not on a per-lsp basis

I have no issue with this. The change, however, is one of semantics. That is, if
you want *hard* preemption to occur at the preempting node (i.e. LSP teardown to
begin at the preempting node) this will require a new session attribute. As I
hope I made clear, my opinion is that preemption is already soft by default.

> and

This is not an issue for the preempting node to manage on behalf of the ingress.
Rather, it is an issue for the ingress to manage for the LSP, and the preempting
node to manage on its own behalf.

You would be better to have the preempted node report the time for which it will
continue to allow over subscription when it reports the preemption.

Anyway, nothing I have been shown, RFC2702 notwithstanding, suggests to me other
than the current correct behavior of upstream nodes receiving a PathErr
reporting preemption is to keep the LSP in place. This is why the state removal
flag was introduced to the PathErr.

Cheers,
Adrian