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

"Adrian Farrel" <> Wed, 28 May 2014 09:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 218731A08A3; Wed, 28 May 2014 02:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.639
X-Spam-Status: No, score=-101.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tnKeLiXXZQUy; Wed, 28 May 2014 02:42:40 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5EA31A08A6; Wed, 28 May 2014 02:42:35 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id s4S9funE016271; Wed, 28 May 2014 10:41:56 +0100
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s4S9fqnF016235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 May 2014 10:41:53 +0100
From: "Adrian Farrel" <>
To: "'Tina TSOU'" <>, <>, "'The IESG'" <>, <>
References: <>
In-Reply-To: <>
Date: Wed, 28 May 2014 10:41:54 +0100
Message-ID: <03b801cf7a59$10339e10$309ada30$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B9_01CF7A61.71FB1350"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHuqFyJr618hkIR4SkkIQUNznzMUJsXYEtw
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--17.013-10.0-31-10
X-imss-scan-details: No--17.013-10.0-31-10
X-TMASE-MatchedRID: yebcs53SkkB5X0FJZbmEplaOpp/sV5nVOhJ9m53n4aBaW2Ktn+I8/gNz NPuvThWtkSqH+Kc9BkIQDZh9tV+I0ba2Vh2jQ2eErA6HcPclJMa1k3bRIdXVNLrfxlRjqBJ3Ffu 9xZgL7lcaGJ6hc5LcclmOdb8MqKJnIb5y7s6OC0xbuDP8ZuCmXr4kZYg1dp8susef4abk6p0yto nrvDOcsfD5I9mHdz1CRRKksvaWeO53daUeCOH6HfyAR9DgC/hHUCwb19dUaUllbnk1HqKhKjJ2n cI9Ab5F4FPBvB8THgwkyJUnPwZoviC92D94UBz+ZwmQqXe/8sNfjyTZEf6/10Yx760ONDcW9c93 RvN2G/cu/7HsWD1fMNopkMzURarkBdPqXpSPY10tR8fVMTBo3dIv4RV84lHTRL9uhZIYy10+avt yet/ecDAkDQ4MCPBMn35cKPv4RPYamKBTix5It3yisJcA82QktDSfcMR+7ZPn0JXek/DSxTnSYw R4FpNFBSuHQ7HM64ukt1bypCWySufehSI6eWNzpkIW3Gref32gF68P3HFTmci9AjK6C8p1biGmw SWrlIAcl4Vrs6KMmBIaAHp9icVsZP2HNi+vOdZjuN6nCSmvr6TYf9v9floldDwP5ItpCOwcSRF9 JP5Ozi4jb1n1eNA3hzKlTm8jzDLDWFe972ARUI7Su3QulAZ5FKliqHKCaOnrKAwxOgrz3aeFnJs qgWxcQt2470g7vecsWi4sXciGhT8G3G/wjVDpcLw8nYQVLsggFyxci4S+VuRnWbJNcqgXKqHlxT J7eJUibp8py4XIryhHQrcMnybC1lfDCm9+EZWeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vXkguuQorcgMrjzoJQxQwa4C4tIeVX3Agh38xpL4Ps3Stazz1MQ8tR9+3BndfXUhXQ==
Subject: Re: [secdir] Secdir review of draft-ietf-pce-pcep-inter-domain-p2mp-procedure-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 May 2014 09:42:44 -0000

Thank you Tina,
Authors, please look at Tina's review. I don't think there is anything to do in
this draft for Tina's main comment (and we could easily rat-hole in the
discussion of what routing neighbors can do to each other that is "unfriendly"),
but there are quite a few nits you should clean up.
From: iesg [] On Behalf Of Tina TSOU
Sent: 28 May 2014 07:30
To: <>rg>; The IESG;
Subject: Secdir review of draft-ietf-pce-pcep-inter-domain-p2mp-procedure-06
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
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,