Re: [Pce] New Version of draft-zhao-pce-pcep-inter-domain-p2mp-procedures

Olufemi Komolafe <femi@cisco.com> Wed, 02 February 2011 21:33 UTC

Return-Path: <femi@cisco.com>
X-Original-To: pce@core3.amsl.com
Delivered-To: pce@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477473A6D79 for <pce@core3.amsl.com>; Wed, 2 Feb 2011 13:33:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNILPYasf8Xg for <pce@core3.amsl.com>; Wed, 2 Feb 2011 13:33:13 -0800 (PST)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 27E8C3A6DBD for <pce@ietf.org>; Wed, 2 Feb 2011 13:33:13 -0800 (PST)
Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 02 Feb 2011 21:36:33 +0000
Received: from dhcp-144-254-153-56.cisco.com (dhcp-144-254-153-56.cisco.com [144.254.153.56]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p12LaW1b029579; Wed, 2 Feb 2011 21:36:33 GMT
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary="Apple-Mail-2-547812891"
From: Olufemi Komolafe <femi@cisco.com>
In-Reply-To: <006501cbb9ba$d40e3e70$7c2abb50$@olddog.co.uk>
Date: Wed, 02 Feb 2011 21:36:32 +0000
Message-Id: <E6460E7D-F3F7-446A-996D-5A480BC22292@cisco.com>
References: <006501cbb9ba$d40e3e70$7c2abb50$@olddog.co.uk>
To: Daniel King <daniel@olddog.co.uk>
X-Mailer: Apple Mail (2.1081)
Cc: pce@ietf.org, msiva@cisco.com, qzhao@huawei.com
Subject: Re: [Pce] New Version of draft-zhao-pce-pcep-inter-domain-p2mp-procedures
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pce>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2011 21:33:15 -0000

Dan,

I recently read this draft and found it pretty interesting.

However, one main issue that struck me was that the approach in Section 7.2 for the core tree computation seemed very computational expensive.  Unless I'm missing something, It seems like the draft is suggesting computing the VSPTs for every leaf BN and then exhaustively working through all the potential combinations of paths to find the optimal combination for the core tree.  The number of evaluations needed struck me as potentially being very large and made me wonder whether there was a smarter way to try to compute the optimal core tree?    Is it possible to try to split up this computation somehow by distributing it judiciously between the PCEs?  For example perhaps by each PCE essentially computing the optimal core "sub-tree" from each ingress node for the domain to all the "downstream" BNs that are reached exclusively by it?   And then the source PCE has to combine these sub-trees optimally?  I'm not 100% sure that approach will work but nevertheless I think trying to avoid tediously iterating over all possible path combinations to compute the optimal core tree is  worthy of some more consideration.

Some minor typos:
Section 1. Introduction 
Incomplete sentence: "The ability to compute......"

Section 2. Terminology
"lead nodes" instead of "leaf nodes" for Destination

Section 5. Requirements
Points (5) to (8) do not really read like requirements.  Perhaps re-word?

Section 6. Objective Functions
Points (1) to (4) do not really read like objective functions. Perhaps re-word?

Section 7.1 Core Trees
Figure 3: Some of the labels on the right half of the diagram seem incorrect (i.e. should the two (XN3_1)s should be (XN1_2) and (XN3_2) respectively?)

Section 7.4.1 The Extension of RP Object
Errors in second sentence of text for C bit value of 1

Section 7.4.2 The PCE Sequence Object
Second sentence: "this objects"

Regards,
Femi

On 21 Jan 2011, at 22:30, Daniel King wrote:

> Hi All,
>  
> We have created a new version of draft-zhao-pce-pcep-inter-domain-p2mp-procedures (07).
>  
> http://www.ietf.org/id/draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07.txt
>  
> This version was created to fix a number of minor edits, raise the issue of  manageability and help facilitate protection scenarios discussed during IETF 79 in Beijing. The draft update includes:
>  
> 8. Protection Section
> This section is used to highlight issues discussed in Beijing. Thanks to JP and all for your questions. We expect this topic to require more discussion and one scenario is that it should be addressed in separate document. The whole protection topic (not just for P2MP and multi-domain) will require a much more detailed analyses and we will follow-up on the various issues with a separate email/discussion.  
>  
> 9.  Manageability Considerations
> Obviously management of inter-domain P2MP path computations potentially raise a number issues and we have begun to document them. Each sub-areas will require further deliberation so please feel free to comment and make suggestions.
> Finally, the authors would like to request working group adoption of this draft.
>  
> Thanks!                                                                                                                  
> Quintin
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce