The MPLS WG Archive

[Jean Philippe Vasseur <jvasseur@cisco.com>]

Hi Adrian,

At 05:07 PM 1/13/2004 +0000, Adrian Farrel wrote:
>All,
>
>Thank you to those of you who have responded to me privately as part of 
>the debate on
>pre-emption. It is, perhaps, indicative that the level of comments has 
>been so low.
>
>I can summarize the responses as follows. Mainly, people fall into just 
>one of the
>categories. I present them here without comment.
>
>1. Pre-emption behavior is clearly defined in RFC2205 and RFC3209.
>     It is defined as SOFT pre-emption. The correct behavior of an LSR
>     is to RETAIN state after pre-emption both on the pre-empting LSR
>     and on the upstream and downstream LSRs. State is only removed
>     by explicit teardown or by soft state timeout.
>     Any application that removes state on the receipt of a PathErr or
>     ResvErr is not conformant to the RFCs.
>
>1a. Given 1., it is necessary to fix the broken implementations. No
>       additional work is needed for hard pre-emption given RFC3473.
>
>1b. Given 1., it is necessary to change the RFCs to match the
>       implementations. It may then be necessary to devise new soft
>       pre-emption techniques.
>
>2. Pre-emption behavior is clearly defined in RFC2205 and RFC3209.
>     It is defined as HARD pre-emption. The correct behavior of an LSR
>     is to DISCARD state after pre-emption both on the pre-empting LSR
>     and on the upstream and downstream LSRs.
>     Implementations that do not discard state are broken.
>     New pre-emption techniques are required to effect soft pre-emption.

I think that one cannot make the statement that RFC3209 clearly defines the 
expected behavior regarding preemption (Hard or Soft). As a matter of fact, 
several route vendors made a similar choice, interpreting the default 
behavior as a "Hard preemption". Another fact is that thousands of LSRs run 
those codes in the Internet.

If we think that the expected behavior has to be clarified which is 
probably the case since we would not have this debate, then, I would vote 
for an BCP specifying that the default mode is "Hard Preemption" (your 
option B below) in accordance with the existing implementations and 
networks in production. You can count me in to help out.

Comment: considering the option of retaining the states and releasing the 
cross-connect is in my opinion clearly not desirable at it makes the 
control plane non congruent with the data plane and may lead to some 
undesirable effects.

Thanks.

JP.

>3. There is a difference between retaining state and retaining cross-
>     connects. It is possible to discard cross-connects (at pre-empting
>     LSR, and at upstream and downstream LSRs) without discarding
>     state.
>
>4. Spending time on pre-emption is a waste of effort. Pre-emption is
>     a requirement to fix a TE subscription model that is fundamentally
>     broken. In particular, there is no convenient mapping of data priority
>     and importance to pre-emption priority.
>     Pre-emption is only necessary in networks that do not apply centralized
>     management of resources (since with centralized management the same
>     effect is achieved using correct grooming of LSPs).
>
>
>There is a choice of three actions.
>
>A. Clarify the expected behavior of the LSRs in accordance with the
>      existing RFCs to specify soft pre-emption. Specify hard pre-emption as
>      described in RFC3473. Probably write an informational RFC or BCP.
>      Let any "broken" implementations worry about their non-conformance.
>      [Addresses 1a. and 3.]
>
>B. Clarify the expected behavior of the LSRs in accordance with the
>      existing RFCs to specify hard pre-emption. Probably write an
>      informational RFC or BCP.
>      Let any "broken" implementations worry about their non-conformance.
>      Specify a new protocol for soft pre-emption.
>      [Addresses 1b. and 2.]
>
>C. Don't do anything.
>
>
>I have my opinions, but this choice is for the WG, WG chairs and ADs.
>
>Thanks,
>Adrian