[CCAMP] comments to draft-gandhi-ccamp-gmpls-restoration-lsp-01

"Zhangxian (Xian)" <zhang.xian@huawei.com> Fri, 08 November 2013 02:23 UTC

Return-Path: <zhang.xian@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC7521E80BA for <ccamp@ietfa.amsl.com>; Thu, 7 Nov 2013 18:23:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.057
X-Spam-Level:
X-Spam-Status: No, score=-6.057 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4Er4r4ixsfm for <ccamp@ietfa.amsl.com>; Thu, 7 Nov 2013 18:23:06 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 411D321E817C for <ccamp@ietf.org>; Thu, 7 Nov 2013 18:23:05 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXQ87160; Fri, 08 Nov 2013 02:23:04 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 02:22:20 +0000
Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 02:23:03 +0000
Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.140]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.03.0158.001; Fri, 8 Nov 2013 10:22:57 +0800
From: "Zhangxian (Xian)" <zhang.xian@huawei.com>
To: "ccamp@ietf.org" <ccamp@ietf.org>
Thread-Topic: comments to draft-gandhi-ccamp-gmpls-restoration-lsp-01
Thread-Index: AQHO3CkIHG8ruuUI/EGpdh6NlTsP5Q==
Date: Fri, 08 Nov 2013 02:22:57 +0000
Message-ID: <C636AF2FA540124E9B9ACB5A6BECCE6B263E05B4@szxeml510-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.150.88]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [CCAMP] comments to draft-gandhi-ccamp-gmpls-restoration-lsp-01
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Nov 2013 02:23:11 -0000

Hi, All, 

    Due to short of time, I post my questions to this draft here (based on the slides).  

1) what is the scope of this document? From the examples given, it seems to me only to end to end case. If it is not the intention, it would be good to clarify. 

2) Page 3 of the slides, last sentence. 
I do not think it is accurate. A restoration LSP can be established before failure as specified in RFC4872, unless you are targeting fully dynamic rerouting. So i think the following text in the draft need modification:

"Restoration LSP differs from a secondary LSP
   in the way that secondary LSP does not reserve resources in the data
   plane and is not able to carry any traffic until it is refreshed
   whereas restoration LSP does reserve resources and is able to carry
   traffic."

3) Page 8, the note. 
Could you point the exact piece of text saying this in RFC6689? At the moment, i cannot find it, thus cannot judge the need of this draft. 

4) Page 9: 
4.1: It seems to me the draft are using the bit P different from what it is defined in  RFC4872. Since it is a BCP draft, i do not expect this. Please clarify. 

4.2: not sure why assign a restoration LSP for a protection LSP? If the intention is to protection two failures, assign one protection and one restoration LSP for the working LSP is probably a better way to do. Since the failure of protection LSP does not won't trigger any update in RSVP-TE. 


Regards,
Xian