The MPLS WG Archive

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

Hi Adrian,

See in line,

At 06:18 PM 1/27/2004 +0000, Adrian Farrel wrote:
>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 :-)

I fully agree.


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

While ideally the final position would not require any "migration"

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

Perfect. If you need any help, just let me know.

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

Perfect the,

Thanks

Cheers,

JP.

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