Re: [CCAMP] Network Assigned Upstream Label - Draft Update

"Zhangxian (Xian)" <zhang.xian@huawei.com> Tue, 25 February 2014 10:59 UTC

Return-Path: <zhang.xian@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D031A0382 for <ccamp@ietfa.amsl.com>; Tue, 25 Feb 2014 02:59:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.297
X-Spam-Level:
X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHW_eoXSC6Se for <ccamp@ietfa.amsl.com>; Tue, 25 Feb 2014 02:59:31 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C10FA1A03CD for <ccamp@ietf.org>; Tue, 25 Feb 2014 02:59:30 -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 BBM34603; Tue, 25 Feb 2014 10:59:29 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Feb 2014 10:59:20 +0000
Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Feb 2014 10:59:26 +0000
Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.22]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Tue, 25 Feb 2014 18:59:19 +0800
From: "Zhangxian (Xian)" <zhang.xian@huawei.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Thread-Topic: [CCAMP] Network Assigned Upstream Label - Draft Update
Thread-Index: AQHPMdsqJ9mr7x5YJ0OYw9lks1pB6prFg5MA
Date: Tue, 25 Feb 2014 10:59:19 +0000
Message-ID: <C636AF2FA540124E9B9ACB5A6BECCE6B3020B63F@SZXEMA512-MBS.china.huawei.com>
References: <CA+YzgTt-mZO4dTKc5_diQJPmttpX=wFC66X3u9U56oQso8iNMw@mail.gmail.com>
In-Reply-To: <CA+YzgTt-mZO4dTKc5_diQJPmttpX=wFC66X3u9U56oQso8iNMw@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.104.209]
Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B3020B63FSZXEMA512MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/fZNUbee1bfv7tu25RNICwpNLi0g
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 25 Feb 2014 10:59:33 -0000

Hi, Pavan,

     I understand this draft intends to allow bidirectional LSP setup with the capability of downstream nodes specifying the upstream label (assume label symmetry). I have a couple of questions/comments, could you please clarify?

1)      This draft is only applicable to networks with continuity constraint, for now I can only think of WSON, probably Flexi-grid/SSON is applicable as well. Because for other cases, such as OTN, it is perfectly fine for the nodes to specify upstream label starting from the source node. Is the scope correct?



2)      In this draft, it is assumed that the label assigned will always be symmetric (i.e., upstream and downstream label is equal). Thus, IMHO, using the mechanism specified by RFC3473 for unidirectional LSP setup (i.e., downstream label assigned by the destination node will also enable upstream label selected) can solve the problem. It does not require protocol extensions, although probably some operational policy should be in force to ask the nodes in the data plane to configure the resource in both directions. How do you see your solution better/different than this one?



3)      The use case specified is the only use case (not general enough) or you also have other use cases in mind?

Regards,
Xian

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Vishnu Pavan Beeram
Sent: 2014年2月25日 11:38
To: ccamp@ietf.org
Subject: [CCAMP] Network Assigned Upstream Label - Draft Update

Folks, Hi!

We recently published a new version of the "Network Assigned Upstream Label" draft (http://tools.ietf.org/html/draft-beeram-ccamp-network-assigned-upstream-label-02). This new-version addresses all the comments that were raised against the version presented in Vancouver. Please read it through and let us know if there are any fresh comments.

Regards,
-Pavan (on behalf of the authors)
ps: Attached slideset (pdf) gives a quick overview of the draft