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

JP Vasseur <jvasseur@cisco.com> Fri, 05 March 2010 10:09 UTC

Return-Path: <jvasseur@cisco.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B293A8F48; Fri, 5 Mar 2010 02:09:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.549
X-Spam-Level:
X-Spam-Status: No, score=-9.549 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpOaP14XRuvE; Fri, 5 Mar 2010 02:09:01 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D92DF3A8F47; Fri, 5 Mar 2010 02:09:01 -0800 (PST)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAI1nkEutJV2d/2dsb2JhbACbRXOccphohH0E
X-IronPort-AV: E=Sophos;i="4.49,586,1262563200"; d="scan'208";a="492079359"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by sj-iport-6.cisco.com with ESMTP; 05 Mar 2010 10:08:58 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o25A8X4m005221; Fri, 5 Mar 2010 10:08:57 GMT
Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 11:08:45 +0100
Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 11:08:44 +0100
Message-Id: <C237A2EC-4944-407C-9739-5722CCB56B14@cisco.com>
From: JP Vasseur <jvasseur@cisco.com>
To: Jie Dong <dongjie_dj@huawei.com>
In-Reply-To: <06e501cabc2e$2d855230$bf0c6f0a@china.huawei.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 05 Mar 2010 11:08:41 +0100
References: <06e501cabc2e$2d855230$bf0c6f0a@china.huawei.com>
X-Mailer: Apple Mail (2.936)
X-OriginalArrivalTime: 05 Mar 2010 10:08:44.0776 (UTC) FILETIME=[D6EAC680:01CABC4B]
Cc: mpls@ietf.org, ccamp@ietf.org
Subject: Re: [mpls] [CCAMP] New Draft Notification: draft-dong-ccamp-rsvp-te-plr-designation-00
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Mar 2010 10:09:02 -0000

On Mar 5, 2010, at 7:36 AM, Jie Dong wrote:

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

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.

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