The MPLS WG Archive

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

Thanks JP.

In line...

> >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).

Several people have made this statement. It is an opinion.

I believe the debate over which is right or wrong will prove to be extremely unhelpful in
the long term :-)

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

The first fact is part of the debate about clarity and right/wrong, so I won't comment
further.
The second fact is undoubtedly important for the IETF. It should not change the long-term
solution, but it may change the migration path to the long-term solution (and I say that
without any comment about what the long-term solution is).

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

Thank you for your offer.
I am looking at more than a BCP. A BCP implies that this is an operational choice. I do
not think we want that because if two adjacent LSRs make a different choice the network
will be broken.

At the moment I am building a strawman draft. I expect that it will be duly knocked down,
kicked, shredded and burned. But we have to start somewhere! Expect to see it published in
a few days.

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

Clearly a control plane state that does not know the hardware state is not a good idea.

Really, however, I would prefer that we do not get into a debate on opinions 1 through 4.
Better to spend our time on solutions A through C. The draft I am writing is trying to be
cunning and combine solutions A and B.

Cheers,
Adrian

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