The MPLS WG Archive

["Adrian Farrel" <adrian@olddog.co.uk>]

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.

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