The MPLS WG Archive

[Dimitri.Papadimitriou@alcatel.be]

hi adrian, all,

see in-line (good summary by the way):

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

the correct thing to do soft-preemption is ubiquitous to (G)MPLS
from RFC2205/3209 and hard preemption make use of RFC 3473

-> my preference goes to this action point, however in order to
allow "broken" implementation to step in here, a mechanism making
use of the following "flag: soft-preemption (per RFC2205/3209) not
in use"

i'd like to propose to include this in the drafted document as
"conclusion" for actions to be potentially performed

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

then one has  two implementation of hard preemption RFC3473 and
the RFC2205/3209 in fact we've an issue that hard preemption is
thus specific to MPLS vs GMPLS !

> C. Don't do anything.
> 
> 
> I have my opinions, but this choice is for the WG, WG chairs and ADs.
> 
> Thanks,
> Adrian
> 

-- 
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
E-mail : dpapadimitriou@psg.com
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491