Subject: [Pce] Questions on draft-king-pce-hierarchy-fwk

From: "Filippo Cugini" <[email-masked]>
Date: Mon, 10 Jan 2011 11:40:19 +0100

Authors, all,
a couple of comments/questions 

- particularly in the context of a single service provider, the view of child domains as vertices might not be so effective. 
For example, if domains are routing Areas, no TE info can be really used at the parent PCE and the optimal solution is achieved only through path computation flooding, with possible scaling issues (as in BRPC flooding).
Maybe the case of a single service provider (which is also not affected by confidentiality issues) could be addressed using a different hierarchical solution.
What do you think about it?

-  In Sect 5.8.4, the possible use of PCNtf is indicated. 
As suggested, a mechanism to configure refresh intervals should be introduced.   
In addition, for example when the H-PCE TED needs to be re-built (e.g., upon faults), a mechanism to enable the H-PCE to solicit/request domain connectivity info might be required.
Nothing against the use of PCNtf or new PCEP messages to carry reachability and link TE info, just wondering if this will tend to reproduce a routing protocol within PCEP. 
This point will become more relevant in case of a larger amount of TE info to carry, i.e., with reference to the previous point, if a mesh of virtual intra-domain TE links between border nodes will be eventually enabled for some scenarios (e.g., single service provider). 

Thank you
  Filippo

---

From: Ramon Casellas <[email-masked]>
Date: Wed, 19 Jan 2011 11:49:54 +0100

Filippo, all,

Some comments and subjective views inline. I guess Dan / other draft 
author can give you a better (or different) answer but, for what is 
worth, here's mine

On 10/01/2011 11:40, Filippo Cugini wrote:
> Authors, all,
>
> - particularly in the context of a single service provider, the view 
> of child domains as vertices might not be so effective.
> For example, if domains are routing Areas, no TE info can be really 
> used at the parent PCE and the optimal solution is achieved only 
> through path computation flooding, with possible scaling issues (as in 
> BRPC flooding).
> Maybe the case of a single service provider (which is also not 
> affected by confidentiality issues) could be addressed using a 
> different hierarchical solution.
>

Personally, I am open to other TED aggregation schemes, where the 
topology of a child domain is more detailed than a simple node, 
specially in the case of intra-carrier and  inter-domain (e.g. areas 
within an AS or vendor boundaries) although as seen in past mails it is 
clearly not a consensus. I see no particular reason why a p-pce would 
not be able to construct more detailed (yet abstracted) child 
topologies, even if the two step-process "determine domain sequence" + 
"expand intra-domain" is kept and it helps the p-pce to carry out a 
better domain chain selection. In a quite straightforward manner we 
considered a  "one star topology per domain" with limited extensions. I 
understand some opponents view in the difficulty of mapping all TE link 
attributes into virtual parent topologies and it's true that most 
academic work only focuses on reduced aspects such as bandwidth and delay.

Although both the framework and the companion protocol extensions 
document are somehow targeted to the scenario you mention (child domains 
as vertices), I think that they seem to be both open/generic enough to 
accommodate other approaches in which the child domains are more 
detailed than a simple "node representation", maybe with some tweaks.

However, as detailed below, allowing for flexible aggregation mechanisms 
opens new issues.

> As suggested, a mechanism to configure refresh intervals should be 
In theory, with the "one vertex per domain", it does not seem necessary 
to consider refreshes beyond the straightforward approach of sending a 
PCNtf "when there is a change in the interdomain link", although nothing 
prevents you from adding better refresh policies.

However, if/when considering more complex topology aggregation 
mechanisms, refresh intervals are in my view, only one part of the 
problem, bound to the mechanism by which a c-pce aggregates a topology 
towards the parent, which I would guess is not subject to 
standardization, (yet?). The mechanism would need to include
i) the process by which a graph G is "transformed" into graph H, usually 
with less number of vertices/edges
ii) how graph H is communicated to the p-pce and how refreshes are managed
iii) how a "path" in graph H is mapped back to graph G

I think only ii) should be addressed by PCE wg.Existing implementations 
seem to either enable a OSPF-TE adjacency between p-pce and c-pce or 
wrap OSPF-TE TLVs / InterAS opaques in PCNtf messages

> In addition, for example when the H-PCE TED needs to be re-built 
> (e.g., upon faults), a mechanism to enable the H-PCE 
> to solicit/request domain connectivity info might be required.
> Nothing against the use of PCNtf or new PCEP messages to carry 
> reachability and link TE info, just wondering if this will tend to 
> reproduce a routing protocol within PCEP.
I am not sure. On the one hand, the PCNtf is straightforward enough to 
use and implement, and the simplicity of decoupling the p-pce from the 
c-pce, not requiring the existence of an OSPF-TE adjacency and limiting 
the interaction c-pec / h-pce to the PCEP/TCP session seems a "nice to 
have". On the other hand, it is easy and dangerous to re-invent the 
wheel with PCNtfs being the new "wrapper" for OSPF-TE.

> This point will become more relevant in case of a larger amount of TE 
> info to carry, i.e., with reference to the previous point, if a mesh 
> of virtual intra-domain TE links between border nodes will 
> be eventually enabled for some scenarios (e.g., single service provider).

Agreed. I guess my point is that current drafts do not (necessarily) 
preclude better (for some definition of better, even if they are just to 
somehow convey the fact that a transit domain may not provide 
connectivity to all potential neighbor domains) aggregation mechanisms, 
and although the whole actual process by which a child-PCE "summarizes" 
a domain should not be subject to standardization, the c-pce p-pce 
communication may be and PCNtf wrappers are not optimal and for those 
cases a dedicated OSPF-TE adjacency with the parent may be more effective.

Thanks for reading and best regards,
Ramon

-- 
Ramon Casellas, Ph.D.
Research Associate - Optical Networking Area --http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
Av. Carl Friedrich Gauss 7 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 16 -- Fax. +34 93 645 29 01