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

Gregory Mirsky <gregory.mirsky@ericsson.com> Tue, 11 June 2013 18:32 UTC

Return-Path: <prvs=7874684126=gregory.mirsky@ericsson.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 354BD21F9799; Tue, 11 Jun 2013 11:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 STqAcTEcFwtG; Tue, 11 Jun 2013 11:32:13 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6583C21F9811; Tue, 11 Jun 2013 11:32:12 -0700 (PDT)
X-AuditID: c618062d-b7f936d000004481-bc-51b76d2b6b7d
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B9.3B.17537.B2D67B15; Tue, 11 Jun 2013 20:32:11 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Tue, 11 Jun 2013 14:32:10 -0400
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Mach Chen <mach.chen@huawei.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+Bl4MHVP2MgA690VAAIXnbXA=
Date: Tue, 11 Jun 2013 18:32:09 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1121B4A14DF@eusaamb103.ericsson.se>
References: <7347100B5761DC41A166AC17F22DF1121B4A0E8C@eusaamb103.ericsson.se> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAEAA2@szxeml558-mbs.china.huawei.com>
In-Reply-To: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAEAA2@szxeml558-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.134]
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B4A14DFeusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyuXRPuK527vZAg6PrZCwurBW2uLV0JavF isfvWC36Pm1hsWg+dordgdWj5chbVo8lS34yeVx6cYgtgDmK2yYpsaQsODM9T98ugTvjyMLj 7AVHtzBVdF3dydLAeHgyUxcjB4eEgInEiS8sXYycQKaYxIV769m6GLk4hASOMkr8/vaSHcJZ zihx93MrE0gVm4CRxIuNPWAJEYG3jBK/pvaxgSSEBVwltrQ3gBWJCLhJTO1dwAZhW0msXL6Z FcRmEVCV2HtzGdg6XgFfifUPV0NtmMkosWbNPLBmToEwiRfLt4IVMQLd9P3UGrA4s4C4xK0n 85kgbhWQWLLnPDOELSrx8vE/VghbWWLJk/0sEPX5EjdO7GSDWCYocXLmE5YJjCKzkIyahaRs FpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvoqRo7Q4tSw33chgEyMw2o5JsOnuYNzz 0vIQozQHi5I4rxrv4kAhgfTEktTs1NSC1KL4otKc1OJDjEwcnCCCS6qBcerluGuXmdX3PxLs XB1SIsYd/sE/oPkmw64czzD2b/M7jU5fFJpfpCEdUfHoy8OcveaPVtxkNbt85/HLJ9bbu9a/ Wx8xjf2HUfGuWoGj1WtW5nqeEmaw2vZnxcqFDB03JFhex1xa3JTRfij17Hm3H2v/XZYvaEk6 udnb2OTDsdZN5jo1fjc+/VNiKc5INNRiLipOBAAyZepLiQIAAA==
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: Tue, 11 Jun 2013 18:32:20 -0000

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