Re: [mpls] [CCAMP] New Draft Notification: draft-dong-ccamp-rsvp-te-plr-designation-00
Jie Dong <dongjie_dj@huawei.com> Fri, 05 March 2010 06:36 UTC
Return-Path: <dongjie_dj@huawei.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 31D223A8EED; Thu, 4 Mar 2010 22:36:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.846
X-Spam-Level:
X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 A8HmiO+PUo5O; Thu, 4 Mar 2010 22:36:36 -0800 (PST)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 3324B3A89C7; Thu, 4 Mar 2010 22:36:36 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYS00C24QCPGO@szxga03-in.huawei.com>; Fri, 05 Mar 2010 14:36:25 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYS00H2TQCPX1@szxga03-in.huawei.com>; Fri, 05 Mar 2010 14:36:25 +0800 (CST)
Received: from d65110 ([10.111.12.191]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYS00GSEQCOI4@szxml06-in.huawei.com>; Fri, 05 Mar 2010 14:36:25 +0800 (CST)
Date: Fri, 05 Mar 2010 14:36:24 +0800
From: Jie Dong <dongjie_dj@huawei.com>
In-reply-to: <B4E97C5E-3860-46B8-A522-579B6400D079@cisco.com>
To: 'JP Vasseur' <jvasseur@cisco.com>
Message-id: <06e501cabc2e$2d855230$bf0c6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: Acq7qaN5gSxvUQxDQZWnl9Kdgxy/UQAgPe+w
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 06:36:37 -0000
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
- Re: [mpls] [CCAMP] New Draft Notification: draft-… Jie Dong
- [mpls] New Draft Notification: draft-dong-ccamp-r… Jie Dong
- Re: [mpls] [CCAMP] New Draft Notification: draft-… JP Vasseur
- Re: [mpls] [CCAMP] New Draft Notification: draft-… Francesco Fondelli
- Re: [mpls] [CCAMP] New Draft Notification: draft-… Lou Berger
- Re: [mpls] [CCAMP] New Draft Notification: draft-… Jie Dong
- Re: [mpls] [CCAMP] New Draft Notification: draft-… JP Vasseur
- Re: [mpls] [CCAMP] New Draft Notification: draft-… Jie Dong
- Re: [mpls] [CCAMP] New Draft Notification: draft-… Jie Dong