[secdir] Secdir review of draft-ietf-pce-pcep-inter-domain-p2mp-procedure-06

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Wed, 28 May 2014 06:30 UTC

Return-Path: <Tina.Tsou.Zouting@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0E3B01A036F; Tue, 27 May 2014 23:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 2gTvGIgwqV-D; Tue, 27 May 2014 23:30:21 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1BC1A0376; Tue, 27 May 2014 23:30:20 -0700 (PDT)
Received: from (EHLO lhreml203-edg.china.huawei.com) ([]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHH81182; Wed, 28 May 2014 06:30:15 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com ( by lhreml203-edg.huawei.com ( with Microsoft SMTP Server (TLS) id; Wed, 28 May 2014 07:29:36 +0100
Received: from SZXEML410-HUB.china.huawei.com ( by lhreml404-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Wed, 28 May 2014 07:30:07 +0100
Received: from szxeml557-mbs.china.huawei.com ([]) by szxeml410-hub.china.huawei.com ([]) with mapi id 14.03.0158.001; Wed, 28 May 2014 14:29:59 +0800
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
To: "<secdir@ietf.org>" <secdir@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-pce-pcep-inter-domain-p2mp-procedure.all@tools.ietf.org" <draft-ietf-pce-pcep-inter-domain-p2mp-procedure.all@tools.ietf.org>
Thread-Topic: Secdir review of draft-ietf-pce-pcep-inter-domain-p2mp-procedure-06
Thread-Index: Ac96Pf0qE//zx0DMR8GgI7NIsiLOdA==
Date: Wed, 28 May 2014 06:29:58 +0000
Message-ID: <C0E0A32284495243BDE0AC8A066631A8182EEFFB@szxeml557-mbs.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A8182EEFFBszxeml557mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/KOUajfNIMsq8oWlVovy7kjk1H7s
Subject: [secdir] Secdir review of draft-ietf-pce-pcep-inter-domain-p2mp-procedure-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 May 2014 06:30:26 -0000

Dear all,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Technical comments:

This draft focused on solving inter-domain P2MP procedures. The solution is based on a core-tree and corresponding sub-trees construction, with BRPC used as reference. The procedure in this draft is complete and promising for an inter-domain P2MP path computation. However, for future work, following comments may be considered:

Now each PCE is considered friendly with each other, i.e., the cost on the sub-tree will be reflected on the core-tree, and the signals are free to be transmitted correspondingly. But, this is the ideal case, PCE may need to hide some intra-domain information due to some security policies, so that global optimization may not be achieved. In this way, it should be better to split into a few scenarios, such as 'friendly' and 'not friendly' case. In the 'not friendly' scenario, it is also necessary to limit what signal is allowed and what is prohibited. There is no much existing work for this scenario, even for a P2P path computation, so the work for P2MP computation in this scenario should be listed as future work.

In section 1, captions are not numbered correctly. The item "scope" and "Requirements Language" should be section 1.1 and 1.2 respectively.

In section 3, the 5th paragraph, "as discussed in [RFC4461], ...", the last sentence should be changed as follow:
Not only is this selection constrained by the network topology and available network resources, but it is also determined by the objective functions (OF) that may be applied to path computation.

Then in the next paragraph, "Generally, an inter-domain ...", following changes are suggested:
For instance, while the BRPC may be well-suited for P2P paths, P2MP path computation involves multiple branching path segments from the source to themultiple destinations. As such, inter-domain P2MP path computation may result in a plurality of per-domain path options that may be difficult to coordinate efficiently and effectively between among domains.

In the second paragraph from bottom of Section 3, "P2MP Minimum Cost Tree (MCT), ...", following changes are suggested:
P2MP Minimum Cost Tree (MCT), i.e., a computation which guarantees the least cost resulting tree, typically is an NP-complete problem. Moreover, adding and/or removing a single destination to/from the tree may result in an entirely different tree.  In this casethese cases, frequent MCT path computation requests may prove computationally intensive, and the resulting frequent tunnel reconfiguration may even cause network destabilization.

For section 4, the first assumption is suggested to be:
Due to deployment and commercial limitations (e.g., inter-AS peering agreements), the path domain tree willshould be known in advance;

For section 5, the 4th requirements is suggested to change:
      4.  Specifying which nodes are being used as branch nodes SHOULD be supported in the PCReq.

For section 7.2, in the paragraph "Without trimming, the ingress...", the following change is recommended:
Without trimming, the ingress PCE will obtain all the possible S2L sub-paths set for the entry boundary nodes of the leaf domain. The PCE will then, by looking through all the combinations and taking one sub-path from each set to build one tree,  canselect the optimal core-tree.

For section 7.3, in the paragraph "Note that the P2MP path request...", the following change is recommended:
Note that the P2MP path request and response format is as per [RFC6006], where Record Route Object (RRO) areis used to carry the core-tree paths in the P2MP grafting request.

For section 8.1, the following change is recommended:
8.1. End-to-end Protection
   An end-to-end protection (for nodes and links) principle can be applied for computing backup P2MP TE LSPs.  During computation of the core-tree and sub-trees, the computation of protection may also be taken into consideration. A PCE may compute the primary and backup P2MP TE LSP together or sequentially.

Thank you,