Subject: [mpls] New Draft Notification: draft-dong-ccamp-rsvp-te-plr-designation-00

From: Jie Dong <[email-masked]>
Date: Wed, 03 Mar 2010 16:29:21 +0800

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

---

From: JP Vasseur <[email-masked]>
Date: Thu, 4 Mar 2010 15:46:57 +0100

Dear Jie,

Looking at section 3:

    In some scenarios the ingress node may need to specify particular
    LSRs as PLRs, and the protection type of each particular PLR. This
    can be helpful in many aspects. Firstly, this enables the ingress
    node to setup the backup LSPs in a more controllable way. Secondly,
    this could avoid making LSRs which do not have enough resources to
    provide local protections work as PLRs. Thirdly, this could save
    bandwidth reserved for unnecessary backup LSPs.

First argument: why does the proposal allow the ingress node to set up  
the backup LSP ?
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.

Thanks.

JP.

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

> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Francesco Fondelli <[email-masked]>
Date: Thu, 4 Mar 2010 17:12:13 +0100

On Thu, Mar 4, 2010 at 3:46 PM, JP Vasseur <[email-masked]> wrote:
> Dear Jie,
> Second and third arguments: If there is not enough backup bandwidth for
[cut]

fourth argument:

Didn't RFC 4873 already "allow (a) the signaling of
desired LSP segment protection type, (b) upstream nodes to optionally
identify where segment protection starts and stops, (c) the optional
identification of hops used on protection segments, and (d) the
reporting of paths used to protect an LSP."?

I believe you can setup and explicitly control backup
LSPs if you follow RFC 4873 *and* RFC 4090... I've never done it,
though.

Ciao
FF

---

From: Lou Berger <[email-masked]>
Date: Thu, 04 Mar 2010 17:13:46 -0500

Francesco,

If memory serves, you are correct.  See section 2 of RFC4873, search for
4090.

Lou

---

From: Jie Dong <[email-masked]>
Date: Fri, 05 Mar 2010 14:36:24 +0800

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

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

		
		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.

		
		Best regards,
		Jie

---

From: Jie Dong <[email-masked]>
Date: Fri, 05 Mar 2010 16:19:10 +0800

Hi Francesco, Lou, 

Thanks for your comments and information.

> Didn't RFC 4873 already "allow (a) the signaling of desired 
> LSP segment protection type, (b) upstream nodes to optionally 
> identify where segment protection starts and stops, (c) the 
> optional identification of hops used on protection segments, 
> and (d) the reporting of paths used to protect an LSP."?

RFC 4873 provides a way for GMPLS to explicitly control segment recovery.
But the mechanism in rfc4873 may be a bit complex for fast reroute in packet
switch networks. And I am not sure if currently most routers have
implemented this.

This draft is a simple and backward compatible extension to TE FRR defined
in RFC 4090, and the benefit is similar to RFC4873.

> I believe you can setup and explicitly control backup LSPs if 
> you follow RFC 4873 *and* RFC 4090... I've never done it, though.

For a implementation which support both of this, maybe we can. But  this
draft may still be helpful in environments where only rfc4090 is
implemented.

Best regards,
Jie

> -----Original Message-----
> From: Francesco Fondelli [mailto:[email-masked]] 
> Sent: Friday, March 05, 2010 12:12 AM
> To: JP Vasseur
> Cc: Jie Dong; [email-masked]; [email-masked]
> Subject: Re: [CCAMP] New Draft Notification: 
> draft-dong-ccamp-rsvp-te-plr-designation-00
> 
> > for

---

From: JP Vasseur <[email-masked]>
Date: Fri, 5 Mar 2010 11:08:41 +0100

> operators may do not want to reserve such bandwidth for backup LSPs.

That seems a bit awkward to me. Usually if you provision backup  
capacity and you can accommodate
a primary TE LSP, why would you want not to do it ? Then if you cannot  
accommodate them all, there
many existing techniques.
Last but not least such mechanism requires to know the path in advance  
to be effective. What do you
do when you reroute ?

Thanks.

JP.

---

From: Jie Dong <[email-masked]>
Date: Fri, 05 Mar 2010 19:36:46 +0800

> > [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.
> > 	
> 
> That seems a bit awkward to me. Usually if you provision 
> backup capacity and you can accommodate a primary TE LSP, why 
> would you want not to do it ?
SP can choose to protect some specific nodes based on network topology,
resource, policy, etc. 
Sometimes more protection LSPs do not mean higher availability.
There can be a case like this: 
The SP has the knowledge that some nodes on the path are using some other
mechanisms to insure survivability, thus a local repair for such nodes is
unneeded. Thus explicitly inform this can save resources of establishing and
maintaining unneeded backup LSPs. 
In this case, the key point here is not whether there is enough bandwidth,
but to determine whether backup paths are needed. If such backup LSPs are
unnecessary, there is no need to waste bandwidth on them.

Besides, based on RFC 4090, all the nodes(except the egress) along the LSP
will be candidate PLRs and will spend resources on establishment and
maintenance of backup paths. 
With this draft, non-PLR nodes do not need to participate in fast reroute
processing.

> Then if you cannot accommodate 
> them all, there many existing techniques.
Do you mean RFC 4873? 

> Last but not least such mechanism requires to know the path 
> in advance to be effective. What do you do when you reroute ?
I don't get your point here. Could you please give more clarification?

Best regards,
Jie

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