Re: [mpls] Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01

Mach Chen <mach.chen@huawei.com> Thu, 13 June 2013 07:57 UTC

Return-Path: <mach.chen@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5BC21F9A38; Thu, 13 Jun 2013 00:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jX5MPVlhrxeW; Thu, 13 Jun 2013 00:57:54 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1E62621F99E9; Thu, 13 Jun 2013 00:57:51 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASK37160; Thu, 13 Jun 2013 07:57:51 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 13 Jun 2013 08:57:27 +0100
Received: from szxeml459-hub.china.huawei.com (10.82.67.202) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 13 Jun 2013 08:57:40 +0100
Received: from szxeml558-mbs.china.huawei.com ([169.254.8.243]) by szxeml459-hub.china.huawei.com ([10.82.67.202]) with mapi id 14.01.0323.007; Thu, 13 Jun 2013 15:56:20 +0800
From: Mach Chen <mach.chen@huawei.com>
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, "Caowei (Wayne)" <wayne.caowei@huawei.com>, Attila Takacs <Attila.Takacs@ericsson.com>, "ppan@infinera.com" <ppan@infinera.com>, "mpls@ietf.org" <mpls@ietf.org>, "pwe3@ietf.org" <pwe3@ietf.org>
Thread-Topic: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01
Thread-Index: Ac5jzPqpud3c0SMmSem+Bl4MHVP2MgA690VAAIXnbXAATjsfsA==
Date: Thu, 13 Jun 2013 07:56:20 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BB03DE@szxeml558-mbs.china.huawei.com>
References: <7347100B5761DC41A166AC17F22DF1121B4A0E8C@eusaamb103.ericsson.se> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAEAA2@szxeml558-mbs.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B4A14DF@eusaamb103.ericsson.se>
In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B4A14DF@eusaamb103.ericsson.se>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.96.176]
Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BB03DEszxeml558mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [mpls] Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 13 Jun 2013 07:58:00 -0000

Hi Greg,

OK, I am fine with "co-routed".

In addition, regarding to "the C and S bits being simultaneously set", there should be an error code should be signaled, a new status code("The C-bit and S-bit cannot be both set") will be added in the next revision.

Best regards,
Mach

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Wednesday, June 12, 2013 2:32 AM
To: Mach Chen; Caowei (Wayne); Attila Takacs; ppan@infinera.com; mpls@ietf.org; pwe3@ietf.org
Subject: RE: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01

Hi Mach,
yes, I think I see what caused your hesitation "the remote T-PE/S-PEs to establish a new (co-routed) LSP". Frankly, I need to go back to authoritive sources, but I think that signaling of a co-routed LSP is not mandated to be in single Path/Resv pass. I think that if intention is to map PW onto co-routed LSP, then C in C-bit should stand for "co-routed".

    Regards,
        Greg

________________________________
From: Mach Chen [mailto:mach.chen@huawei.com]
Sent: Saturday, June 08, 2013 8:03 PM
To: Gregory Mirsky; Caowei (Wayne); Attila Takacs; ppan@infinera.com; mpls@ietf.org; pwe3@ietf.org
Subject: RE: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01
Hi Greg,

Thanks for your comments!

Yes, it intends to mean co-routed here. Not use the "co-routed" because there is definition of  co-routed bidirectional LSP, where the "co-routed" means not only co-routed but signaled by a single path/resv exchange. If the WG think co-routed is better, I am fine to change to it.

For example, change the C (Congruent Path) bit to C (Co-routed path) bit, and then it's definition would like this:

"C (Co-routed path) bit: This informs the remote T-PE/S-PEs about the properties of the underlying LSPs. When set, the remote T-PE/S-PEs need to select co-routed LSP as the PSN tunnel. If there is no such tunnel available, the node may trigger the remote T-PE/S-PEs to establish a new LSP."

How do you think?

Best regards,
Mach

From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Saturday, June 08, 2013 6:19 AM
To: Mach Chen; Caowei (Wayne); Attila Takacs; ppan@infinera.com; mpls@ietf.org; pwe3@ietf.org
Subject: Comments to draft-ietf-pwe3-mpls-tp-pw-over-bidir-lsp-01

Dear Authors, et al.,
I've prepared some questions and comments that I hope you'll kindly consider:
*         I've got confused by definition of C bit in section 2.1. That might be in part because congruency in geometry has very certain definition and I'm projecting that to term congruent path introduced in the document. In addition I think that "same route" in the second sentence is vague. Does that imply that active PE requests far-end PE to use co-routed LSP? If that is the case, should C bit explained as request to use Co-routed path?
*         Last sentence of section 2.1 defines that detection of C and S bits being simultaneously set as error. How that error being signaled in LDP Status Codes?

        Regards,
                Greg