[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Path Computation Element (PCE) Architecture and mailing list,
- To: "Zafar Ali" <zali@cisco.com>
- Subject: Re: Path Computation Element (PCE) Architecture and mailing list,
- From: ibryskin@movaz.com
- Date: Sat, 9 Oct 2004 10:45:47 -0400 (EDT)
- Cc: pce@ietf.org, "'Adrian Farrel'" <adrian@olddog.co.uk>, 'Ash@movaz.com, "Gerald" <R@movaz.com>, "ALABS'" <gash@att.com>, jpv@cisco.com, mpls@ietf.org, ccamp@ops.ietf.org, zinin@psg.com
- In-reply-to: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com>
- References: <000701c4ad7a$8f896ca0$0300a8c0@amer.cisco.com>
- User-agent: SquirrelMail/1.4.1
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
> 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
>
>