The MPLS WG Archive

[JP Vasseur <jvasseur@cisco.com>]

Hi Igor,

On Oct 9, 2004, at 10:45 AM, ibryskin@movaz.com wrote:

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

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.

> Igor
>
>
>> 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
>>
>>
>
>
> _______________________________________________
> Pce mailing list
> Pce@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/pce
>


_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls