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

Gregory Mirsky <gregory.mirsky@ericsson.com> Fri, 07 June 2013 22:19 UTC

Return-Path: <prvs=987046ee83=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 DEDD521F99AA; Fri, 7 Jun 2013 15:19:06 -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=[AWL=-0.000, 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 TYFkG6S9h3cq; Fri, 7 Jun 2013 15:19:00 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 388D121F99A6; Fri, 7 Jun 2013 15:18:59 -0700 (PDT)
X-AuditID: c618062d-b7f936d000004481-0c-51b25c4d1d4c
Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 5B.4F.17537.E4C52B15; Sat, 8 Jun 2013 00:18:54 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Fri, 7 Jun 2013 18:18:53 -0400
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Mach Chen <mach.chen@huawei.com>, "wayne.caowei@huawei.com" <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+Bl4MHVP2Mg==
Date: Fri, 07 Jun 2013 22:18:52 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1121B4A0E8C@eusaamb103.ericsson.se>
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_7347100B5761DC41A166AC17F22DF1121B4A0E8Ceusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyuXRPrK5fzKZAg5nrpCwurBW2uLV0JavF isfvWC36Pm1hsWg+dordgdWj5chbVo8lS34yeVx6cYgtgDmK2yYpsaQsODM9T98ugTvjeMts poItIhV/F39ga2DsE+xi5OSQEDCR+HFvKROELSZx4d56ti5GLg4hgaOMEvNudLBDOMsYJc5t WcgCUsUmYCTxYmMPWEJE4BujRNuCf2DtwgKOEp9XT2QEsUUE3CSm9i5gg7D1JFa1PmQGsVkE VCQav/9kB7F5BXwl7t8/B1bPCLT6+6k1YHOYBcQlbj2ZD3WSgMSSPeeZIWxRiZeP/7FC2MoS S57sZ4Goz5f4MG0OM8RMQYmTM5+wTGAUmoVk1CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z 4DETsvgCRvZVjBylxalluelGBpsYgZFzTIJNdwfjnpeWhxilOViUxHnVeBcHCgmkJ5akZqem FqQWxReV5qQWH2Jk4uAEEVxSDYxFCrWz79Y+/357Dtf0ybeNJ9oKLrSZyyaxUnBqVjPzJW3T +jXtR2ac0zr3tmehdBqTwl/ZZfFqQesOTn42y3wfy5vN6+xU1/c4O+aaR4s9XFY5q7m1ufd8 yOU1bqtz589XYfY2O315ZcvX52tmmInw/ez0fmd2/u6iCv5zS4Nf50TUqFeqH3JQYinOSDTU Yi4qTgQA0Q8PKW8CAAA=
Subject: [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: Fri, 07 Jun 2013 22:19:07 -0000

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