Dimitri, see in-line.
----- Original Message -----
Sent: Wednesday, July 06, 2005 12:08
PM
Subject: Re: [Pce] PCE Disco Reqs
v01
igor, JL - a couple of comments:
1. On
more than one occasions you use the term "TE-LSP path computation request".
This sounds like an assumption that paths are computed separately for each
TE-LSP. In reality, though, a single path computation request for a protected
service is expected to determine paths for multiple LSPs (working and
protecting). Furthermore, a single path computation may be performed for
multiple services to make them possible sharing protection resources. I
would suggest dropping the "TE-LSP" from the "TE-LSP path computation"
combination;
2. In section 5.1.3 you mentioned among GMPLS capabilities
a capability to compute multi-layer paths. This sounds inaccurate: paths are
always computed in one network layer, however, a capable PCE may
determine/suggest necessary reconfigurations in lower layer(s) in order to
satisfy a particular path computation request;
[dp] i would like to know how you have come to
the second sentence statement - now more specifically, and in the context of
the PCE discovery document, per [LSP-HIER] an incoming ERO may include the
path to the lower SC, procedure is described in section 8.2 of that document
so there is nothing wrong in that sentence it just need a clarification, that
the sequence of hops resulting from this computation may be covering multiple
LSP regions
IB>> Come on, we had this argument many
times already. Note, first, that neither me nor the document mentioned
the term "region". Furthermore, a PSC LSP does not "go" through a
lambda layer, rather, it uses H-LSPs created in the lambda layer as PSC data
links. These links are no different from statically provisioned PSC links with
an exception that the former could be installed and removed by the control
plane. This is what I meant by the "lower layer re-configuration". The ERO
subobjects associated with lambda switching capability is just one (and not
the smartest IMO) way to control such re-configuration. An alternative way,
for instance, would be for a PCE to assume the VNT manager role and
request the lambda H-LSP provisioning *before* responding to the path
computation request.
3. I believe it should be stated more
clearly that 2 stages of PCE discovery are needed: basic stage and
detailed stage. During the basic stage PCE publishes some basic information
about itself (presence, computation scope, etc.) on the network independently
from PCCs. Interested PCCs should be able to participate in the detailed
discovery stage, that is, to establish communication sessions (via PCC-PCE or
a separate protocol) with the PCE to request/subscribe on the PCE detailed
information (capability, CPU power, capacity, status, etc.). This would be
good IMO both from the scalability and security points of view.
[dp] not sure to understand why an
"interested" PCC needs detailed information on the CPU and memory utilisation
at the end why more classical "admission control" and "back pressure"
mechanism can not be used here ?
IB>> In this clause I didn't mean CPU or
memory utilisation, rather, things like PCE sets of constraints that it
can honor, optimization functions, diversity types, etc.
4. Responding to your
questions:
-Is there a need for
the discovery of PCE capacity in terms of
computation power? This
static parameter could be used to
ensure weighted load
balancing of requests in case PCEs do not
have the same capacity.
Yes. It could be achieved by a direct request from a PCC during the
detailed discovery stage (see above).
[dp] this is not the issue, even if the PCC
knows the detailed computation power utilisation the significance of this
information for the PCC itself can not tell to this PCC more than a "don't
use" if it crosses a given threshold since the PCC does not know how much the
request the PCC is going to initiate will consume on the PCE itself - there is
an issue of the significance of the information that needs to be discussed
first before requiring its initial or later stage discovery
-Would it be useful that a PCE report its status as "congested"
in case it is too busy?
PCCs may then use this dynamic
information to prefer a
different PCE.
Yes. It could be achieved by a subscription of
a PCC on the PCE's status change (also during the detailed discovery
stage ).
[dp] as also proposed by JL an event driven
mechanism would be advisable
IB>> As the document states this information
would help a PCC to choose most suitable PCE.
Igor
----- Original Message -----
From: LE ROUX Jean-Louis
RD-CORE-LAN
To: pce <at> ietf.org
Sent: Wednesday, June 29, 2005 8:00
AM
Subject: [Pce] PCE Disco Reqs
v01
Hi all,
Version 01 of the PCE
discovery reqs ID has just been published
http://www.ietf.org/internet-drafts/draft-leroux-pce-discovery-reqs-01.txt
This version takes into account comments
received during Minneapolis session and on the list.
Here are the major changes since 00:
-Added multi-area network case in the problem statement
-Added application scenario (section 4)
-Section 5.1 on
capability discovery modified as per discussions on the list:
-Discovery of PCE location, PCE scopes and domain(s) under control is
mandatory
-Capability discovery
is no longer a MUST
The list of capabilities is
now out of the scope and should be addressed in a
separate document.
-Added section 5.6 on
extensibility
-Added Security section
Section
5.5 (Discovery of PCE capacity and congestion) requires WG feedback:
-Is there a need for the discovery of
PCE capacity in terms of computation power? This static parameter could be
used to ensure weighted load balancing of requests in case PCEs do not have
the same capacity.
-Would it be useful that a PCE report its status as
"congested" in case it is too busy? PCCs may then use this dynamic information
to prefer a different PCE.
Your comments/feedback would be highly
welcome, especially on the above point
Best
Regards,
JL
_______________________________________________
Pce mailing list
Pce <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce
mailing list
Pce <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce
RSS Feed