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

"Daniel King" <daniel@olddog.co.uk> Wed, 16 February 2011 21:28 UTC

Return-Path: <daniel@olddog.co.uk>
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 EB0283A6CBA for <pce@core3.amsl.com>; Wed, 16 Feb 2011 13:28:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 GI3gCAiuQhdU for <pce@core3.amsl.com>; Wed, 16 Feb 2011 13:27:53 -0800 (PST)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by core3.amsl.com (Postfix) with ESMTP id 6DCEB3A6CB0 for <pce@ietf.org>; Wed, 16 Feb 2011 13:27:51 -0800 (PST)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p1GLRfIb020105; Wed, 16 Feb 2011 21:27:41 GMT
Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p1GLRdkH020098; Wed, 16 Feb 2011 21:27:40 GMT
From: Daniel King <daniel@olddog.co.uk>
To: 'Olufemi Komolafe' <femi@cisco.com>
References: <006501cbb9ba$d40e3e70$7c2abb50$@olddog.co.uk> <E6460E7D-F3F7-446A-996D-5A480BC22292@cisco.com>
In-Reply-To: <E6460E7D-F3F7-446A-996D-5A480BC22292@cisco.com>
Date: Wed, 16 Feb 2011 21:27:36 -0000
Message-ID: <010501cbce20$5501fca0$ff05f5e0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0106_01CBCE20.5503AA50"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQE0sOMCZl1QqNacLvJEph8QehVBjwGM+XSjlSZwqhA=
Content-Language: en-gb
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, 16 Feb 2011 21:28:03 -0000

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. 

 

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. 

 

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. 

 

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.t
xt

 

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