Re: [mpls] [CCAMP] New Draft Notification: draft-dong-ccamp-rsvp-te-plr-designation-00
Jie Dong <dongjie_dj@huawei.com> Mon, 15 March 2010 03:16 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 CF39E3A686C; Sun, 14 Mar 2010 20:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.085
X-Spam-Level:
X-Spam-Status: No, score=-0.085 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_56=0.6, 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 PBqEyGTcIoSf; Sun, 14 Mar 2010 20:16:03 -0700 (PDT)
Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 9EE6D3A6809; Sun, 14 Mar 2010 20:16:03 -0700 (PDT)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZA004UTZQNU0@szxga02-in.huawei.com>; Mon, 15 Mar 2010 11:15:59 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZA0030SZQNVP@szxga02-in.huawei.com>; Mon, 15 Mar 2010 11:15:59 +0800 (CST)
Received: from d65110 ([10.111.12.191]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZA0061GZQNHG@szxml04-in.huawei.com>; Mon, 15 Mar 2010 11:15:59 +0800 (CST)
Date: Mon, 15 Mar 2010 11:15:58 +0800
From: Jie Dong <dongjie_dj@huawei.com>
To: 'JP Vasseur' <jvasseur@cisco.com>
Message-id: <01c301cac3ed$d5c196e0$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: AcrD7dVbDOdzw3SzSamAxLH0e4JNHw==
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: Mon, 15 Mar 2010 03:16:06 -0000
Sorry for any duplication. I just found this mail didn't appear in the mailing lists. > > [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 > > > > > 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