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

Olufemi Komolafe <femi@cisco.com> Fri, 18 February 2011 12:34 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 AFABB3A6DA9 for <pce@core3.amsl.com>; Fri, 18 Feb 2011 04:34:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[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 txzRJnsv+Sfp for <pce@core3.amsl.com>; Fri, 18 Feb 2011 04:34:41 -0800 (PST)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6D90F3A6C9D for <pce@ietf.org>; Fri, 18 Feb 2011 04:34:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=femi@cisco.com; l=34340; q=dns/txt; s=amsiport01001; t=1298032514; x=1299242114; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=Y6Aa6cRo3mpq20yzpJw1JkrYCNb6HdYC9q/fVzGqRYY=; b=pkZKwYgHKfBHTURtrZE4cUknrSYGsCz0HX2Zp+Fmu5AAIBjWHtS/3Ea/ x9NSDkjAgwTe2fVu4HmsUqtpkSiS5wzowoOh+Hd80DaIBEyfaNBH8URsr V857hGsixRf9QuHRSuq0dspGYYaUFBMfN0B4zF9oCz+j+DIDLKSvMVg0G A=;
X-IronPort-AV: E=Sophos; i="4.62,186,1297036800"; d="scan'208,217"; a="76681496"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 18 Feb 2011 12:35:13 +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 p1ICZBON018193; Fri, 18 Feb 2011 12:35:11 GMT
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary="Apple-Mail-1--249736206"
From: Olufemi Komolafe <femi@cisco.com>
In-Reply-To: <010501cbce20$5501fca0$ff05f5e0$@olddog.co.uk>
Date: Fri, 18 Feb 2011 12:35:27 +0000
Message-Id: <1CB529AF-04B0-4374-A8E3-875E0726C6D7@cisco.com>
References: <006501cbb9ba$d40e3e70$7c2abb50$@olddog.co.uk> <E6460E7D-F3F7-446A-996D-5A480BC22292@cisco.com> <010501cbce20$5501fca0$ff05f5e0$@olddog.co.uk>
To: Daniel King <daniel@olddog.co.uk>
X-Mailer: Apple Mail (2.1082)
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: Fri, 18 Feb 2011 12:34:44 -0000

Dan,

On 16 Feb 2011, at 21:27, Daniel King wrote:

> Hi Femi,
>  
> Thank you for taking the time to review the document. You make a number of salient points, please see my comments (DK) in line:
>  
> From: Olufemi Komolafe [mailto:femi@cisco.com] 
> Sent: 02 February 2011 21:37
> To: Daniel King
> Cc: pce@ietf.org; msiva@cisco.com; qzhao@huawei.com
> Subject: Re: [Pce] New Version of draft-zhao-pce-pcep-inter-domain-p2mp-procedures
>  
> 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.  
>  
> DK: We are gated by prior requirements for point to multipoint path computation, including Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE [RFC 5862]. Both for SPF and MCT P2MP path computation. Although you make an excellent point, is it necessary to have the optimal core tree? We should defer to the operators to an authoritative response. My personal opinion is that “good enough” is probably suitable. Having said that, consider that inter-domain point-to-multipoint by a PCE is more than likely a pre-planning activity (with a PCEP request being sent from an NMS or planning platform, versus a real-time (although that is relative) request. So if the PCE is requested to compute a point-to-multipoint path, does it really matter if in order to compute the optimal core tree it takes X minutes, given the fact the service will be signaled/established hours or even days later. On the flipside we need to consider requirements for pre-computed backup paths, as well as real-time recovery. I do plan to send out a separate e-mail shortly on the role of the PCE for protection and recovery, for both P2P and P2MP services.

OK, fair enough.

>  
> 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?
>  
> DK: We did originally look at distributed path computation but discounted it. I'd have to go back through my notes but it may be worth reviewing the situation. Actually giving your background (“An Analysis of Scaling Issues in MPLS-TE Core Networks” [RFC5439] and “An Analysis of Scaling Issues for Point-to-Multipoint Label Switched Paths in MPLS-TE Core Networks”), I wonder if it's worth us putting concerted effort into modelling inter-domain point-to-multipoint PCE path computation requests and responses. We could then actually identify any potential scalability issue with the solution proposed, and investigate modifications as necessary.  I will discuss this with the co-authors in more detail.
>  

Yeah, sounds good.  We can discuss further offline.

> 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"
>  
> DK: Excellent thanks again for your diligence and continued contributions.

No problem.

Regards,
Femi


>  
> 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
>