Subject: [mpls] Path Computation Element (PCE) Architecture and mailing list,

From: "Zafar Ali" <[email-masked]>
Date: Fri, 8 Oct 2004 17:05:35 -0400

Hi Adrian, Jerry, JP, et al, 
 
Thanks for putting the PCE Architecture document
(http://www.ietf.org/internet-drafts/draft-ash-pce-architecture-00.txt), I
found it very useful in scoping PCE WG and applicability of PCE in MPLS/
GMPLS TE networks. In the following I have a few questions/ comments about
this ID. 
 
I would also like to request about what would be a tentative agenda for PCE
BOF Part II in DC? I think the discussion in SD went very well in favor of
PCE WG, pending this architecture ID. What is the present plan of record? 
 
- What did you meant by "the level of robustness of the path resources", in
PCC-PCE communication? I am expecting that the client can also specify an
exclude list, include list (this is in addition of SRLG to include/
exclude).  
 
- Can you please elaborate more on advantages of Stateful PCE and what are
the pits fall of using Stateful PCE in a distributed PCE environment. You
have information about Out-of-band TED synchronization but I am thinking
there is some complexity involved in such mechanism and stateful PCE in a
distributed PCE setup. More description on the applicability of Stateful PCE
& Out-of-band TED synchronization would be useful to better scope core vs..
advanced features of PCE. 
 
- When PCE is distributed, are there any considerations in path computation
(minimum guidelines, like constraints based shortest path based on the
specified optimization criteria, optimization criteria does not change for
the same setup when multiple PCE are involved in path computation, etc.) to
make Path Computations in a distributed PCE scheme, that you think we need
to add to the text of this document. 
 
- When a number of disjoint paths are required, we need a mechanism to
specify if near disjoint Paths are acceptable (but this is need not to be in
architecture doc).  
 
The rest of the document look very good to me. 
 
Regards... Zafar
 
_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: [email-masked]
Date: Sat, 9 Oct 2004 10:45:47 -0400 (EDT)

Hi guys,

I think this is a vey sound document. I have a suggestion though.

It would be extreamely useful if a PCE could advertise its capabilities
such as:

a) set of constraints that it can account for (diversity, SRLGs, optical
impairements, wavelenght continuity, etc.)

b) number of switching capability layers (and which);

c) number of path selection criterias (and which);

d) whether it is a stateless path calculator or can send updates about
better paths that might be available in future;

e) whether it can compute P2MP trees (and which types);

f) whether it can ensure the resource sharing between backup tunnels;

g) etc.

This information would help a lot for a potential PCC that dynamically
learns about PCEs available on the network to decide which of them to use.

Igor

---

From: JP Vasseur <[email-masked]>
Date: Mon, 11 Oct 2004 19:43:25 -0400

Hi Igor,

> learns about PCEs available on the network to decide which of them to  

I cannot agree more ! See the two PCE cap related drafts:
	draft-vasseur-ospf--te-caps (and isis)

Such draft would probably ends up being discussed here, should we end  
up creating a WG.

JP.

>> I would also like to request about what would be a tentative agenda  
>> for
>> PCE
>> - What did you meant by "the level of robustness of the path  
>> resources",
>> in
>> distributed PCE setup. More description on the applicability of  
>> Stateful
>> PCE
>> the same setup when multiple PCE are involved in path computation,  
>> etc.)
>> to
>> specify if near disjoint Paths are acceptable (but this is need not  
>> to be
>> in
>> architecture doc).
>>
> Pce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pce
>