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

From: Olufemi Komolafe <[email-masked]>
Date: Wed, 2 Feb 2011 21:36:32 +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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: "Daniel King" <[email-masked]>
Date: Wed, 16 Feb 2011 21:27:36 -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:[email-masked]] 
Sent: 02 February 2011 21:37
To: Daniel King
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Pce] New Version of
draft-zhao-pce-pcep-inter-domain-p2mp-procedures

Dan,

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 

Section 2. Terminology

Section 5. Requirements

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

DK: Excellent thanks again for your diligence and continued contributions. 

Regards,

Femi

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.  

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

---

From: Julien Meuric <[email-masked]>
Date: Thu, 17 Feb 2011 18:21:18 +0100

Hi.

Chair hat off, so non-authoritative answer. :-)

I tend to agree that "good enough" is enough, especially with respect to 
an expensive optimality which might not be my fellow's optimality...

Thanks,

Julien

Le 16/02/2011 22:27, Daniel King a écrit :
> 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.

---

From: Olufemi Komolafe <[email-masked]>
Date: Fri, 18 Feb 2011 12:35:27 +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:
>  
> Subject: Re: [Pce] New Version of draft-zhao-pce-pcep-inter-domain-p2mp-procedures
>  
> Dan,
>  
> 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 

No problem.

Regards,
Femi