Subject: [mpls] I-D ACTION:draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt

From: [email-masked]
Date: Tue, 07 Sep 2004 15:57:48 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Fast Reroute Extensions to RSVP-TE for LSP Tunnels
	Author(s)	: P. Pan, et al. 
	Filename	: draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt
	Pages		: 37
	Date		: 2004-9-7
	
This document defines extensions to and describes the use of RSVP to
establish backup label-switched path (LSP) tunnels for local repair
of LSP tunnels.  These mechanisms enable the re-direction of traffic
onto backup LSP tunnels in 10s of milliseconds in the event of a
failure.
Two methods are defined here.  The one-to-one backup method creates
detour LSPs for each protected LSP at each potential point of local
repair.  The facility backup method creates a bypass tunnel to
protect a potential failure point; by taking advantage of MPLS label
stacking, this bypass tunnel can protect a set of protected LSPs that
have similar backup constraints. Both methods can be used to protect
links and nodes during network failure.  The described behavior and
extensions to RSVP allow nodes to implement either or both methods
and to interoperate in a mixed network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-ietf-mpls-rsvp-lsp-fastreroute-07.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-rsvp-lsp-fastreroute-07.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.
_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Erblichs <[email-masked]>
Date: Tue, 07 Sep 2004 17:36:36 -0700

Here a re a few quick comments:

	1) 
	Abstract:
	"10s of milliseconds"

	My assumption is that you are referring to
	a SONETs capability of detecting a Link status
	change in approx 10ms.. Additional ms delays
	are expected.

	When OSPFs Router-dead-Interval's of 10s of
	seconds (ethernet) probably precludes the 
	use of this extension,

	Thus I would suggest a re-wording of
	"These mechanisms enable"

	enables approximately a 10ms SONET's detection
	of a Link down status to trigger subsequent
	redirection of traffic onto temporary alternative
	LSPs known as backup LSPs.

	Additionally...

	All the methods specified within assume that
	backup LSPs can be formed for redirection of
	traffic due to a link-failure using alternate
	paths.

	Questions:

		Should backup LSPs accept lower QOS
		capabilities when equal QOS capabilities
		do not exist?

		What is the order of setting up backup and
		non-backup LSP tunnels?

		If we setup backups first. do we route that
		way until the non-backups are formed? Would
		we assume that it would take less time to
		form the backup LSPs?

		What is the lifetime of a backup LSP?

		How do we withdraw a backup LSP?

	2) One-to-one backup

	In general RSVP has implied scalability concerns
	vs diff-services. With the additional load of
	"One-to-one backup", are those concerns increased?

	I did not see any mention of scalability comparisons
	with this and "Facility backup"? Would the nomenclature
	of "1-2-1" be correctly understood? "1-to-1"?

	3) NITs..

	Should the figures in 5.1 have the ONLY value
	   specified in the field?

	Ex: Class-Num   -> Class-Num = 205

	4) 5.1
	
	Their are two possibly conflicting statements
	dealing with "Class-Num" and "Unknown C-types"
	on how the object should be treated..

	What do we do if Class-Num specifies that a
	"should ignore it and pass if forword unchanged"
	and a C-types says soemthing else? Which has
	precedence?

	NIT, I assume that "pass if forward unchanged"
	should be "pass IT forward unchanged".. If I am
	wrong, you want a node that doesn't understand
	a object to possibly change it, then maybe forward
	it........

	Mitchell Erblich