Re: [CCAMP] New Draft Notification: draft-dong-ccamp-rsvp-te-plr-designation-00

Hi JP,

Thanks for your comment. please see my replies begin with [Jie].

First argument: why does the proposal allow the ingress node to set up the
backup LSP ?

[Jie] This draft is not to allow the ingress to explicitly setup backup
LSPs, but to allow it have more control on the establishment of backup LSPs.
Such control may be helpful to reduce unnecessary back LSPs based on
information of the network and operators' policy.

Second and third arguments: If there is not enough backup bandwidth for the
set of backup LSP, just use the 
"bandwidth protection desired" bit. Nothing prevents you for having 0-bw
backup LSP and non 0 bw backup 
LSP that use that bit to only book backup capacity when required.

[Jie] This can be a solution for controlling backup LSPs, but it may not
work in all scenarios. One example is even when there is enough bandwidth,
operators may do not want to reserve such bandwidth for backup LSPs.

Best regards,
Jie

	On Mar 3, 2010, at 9:29 AM, Jie Dong wrote:

		Dear all, 

		There is a new internet draft:
draft-dong-ccamp-rsvp-te-plr-designation-00:

http://tools.ietf.org/html/draft-dong-ccamp-rsvp-te-plr-designation-00

		The abstract is as follows: 

		This document defines RSVP-TE extensions which enable the
ingress node to
		designate particular LSRs along the path as Points of Local
Repair (PLRs) of
		the protected LSP, and further indicate the protection type
of each PLR.
		These mechanisms could enhance the control over the
establishment of backup
		LSPs, and also could save the resources needed for
establishing and
		maintaining unnecessary backup LSPs.

		Comments are appreciated.

		Best regards,
		Jie

		_______________________________________________
		CCAMP mailing list
		CCAMP@ietf.org
		https://www.ietf.org/mailman/listinfo/ccamp