The MPLS WG Archive

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

All,

I have published a draft to start the ball rolling in the great hard/soft pre-emption
debate.
There is no doubt that the draft is rambling and wrong.

Please enter into a detailed and heated debate.

In summary...

The points of contention are:
- Should pre-emption cause the associated LSP to be torn down
  - at the point of pre-emption
  - at all other LSRs along the LSP?
- If it is torn down, is it torn using PathErr and ResvErr?
- What is the correct processing of a PathErr after an LSP has
   been successfully established.
- Is it possible for hard and soft pre-emption to co-exist in a
   network if they both use the same signalling technique?

A lot of the answers seem to hang on how admission control is performed. Is it per LSP or
is it statistical?

It does not appear to be very fruitful to investigate
- the 'correct' interpretation of RFC3209
- the motivation for the Path_State_Removed flag in RFC3473
(You are, however, perfectly free to investigate whatever you like!)

Cheers,
Adrian

----- Original Message ----- 
From: <Internet-Drafts@ietf.org>
To: <IETF-Announce:>
Sent: Tuesday, December 02, 2003 8:35 PM
Subject: I-D ACTION:draft-farrel-mpls-preemption-interim-00.txt


> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> Title : Interim Report on MPLS Pre-emption
> Author(s) : A. Farrel
> Filename : draft-farrel-mpls-preemption-interim-00.txt
> Pages : 0
> Date : 2003-12-2
>
> This document is an interim report into pre-emption in MPLS systems.
>
> At the 58th IETF, the MPLS Working Group determined that there are
> several interpretations of how pre-emption should be achieved within
> MPLS systems. This document is the result of the initial enquiries to
> vendors and other implementors into the question of how and why they
> offer pre-emption funtion in their MPLS inplementations.
>
> This document is intended to be a short-lived document and only
> exists to document the current findings. It will be superceded or
> retired.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-farrel-mpls-preemption-interim-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-farrel-mpls-preemption-interim-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@ietf.org.
> In the body type:
> "FILE /internet-drafts/draft-farrel-mpls-preemption-interim-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>