Hi, Jean-Louis
See inline, please.
----- Original Message -----
Sent: Monday, June 19, 2006 4:23 PM
Subject: RE: [Pce] Comments on
draft-ietf-pce-disco-proto-igp
Hi Zhang
Thanks for your comments
Please see inline,
Hi, all
I recently read the draft
draft-ietf-pce-disco-proto-igp again, here are some comments。
When IGP is used as a PCED protocol, the
capabilities of pce will be advertised periodicly along with other lsa/lsp
information. In my opinion, unless the PCE's capabilities change,
there is no need for the PCC to receive and handle the information
again.
JLLR: But these are standard IGP procedures. This
is the same for link states, they are refreshed even if there is not
change. By the way the refresh interval can be quite large (e.g. 18 hours
for IS-IS).
Furthermore, if most of the routers
in a domain will always have no request to a PCE, there is also no need
for them to maintain the information.
JLLR: In this case PCE discovery is deactivated
on these routers and they will not process the PCED and PCES
TLVs...
But I don't know if it is possible
for a router to be re-configured as a PCC or have some path
computation request after it receives these TLVs and not processes
them,
Now
if a router is configured as PCC at some point in
time, then it starts processing information carried in PCED and
PCES TLVs...(Before you activate PCE discovery on the PCC the information is
stored but not processed).
My concern to PCE-DEST-DOMAINS sub-TLV is
that we can't anticipate how many destination domains a PCE can
computate path towards, as a result,the length of space taken
by this capality in the message can't be controlled.
JLLR: Actually you have the same problem with the
number of TE-links advertised by an LSR or the number of reacheable
prefixes advertised by an ABR.
One may limit by configuration the number of dest
domains advertised.
But
I still doubt that if it's needed for the PCE to maintain such information and
how a PCE obtains these info?
As discussed latter
this is a really useful feature that helps PCE selection and load
balancing.
In the inter-area case, the
can learn this info both via config and via the IGP (e.g. if the PCE is an
ABR, it can easily know attached
areas).
In the inter-AS case, the
PCE can learn this information both via config and via
BGP.
So I
think if the PCC send a request to a PCE which can't compute the path for
the reason of the destination domain, the PCE can tell the PCC in the
PCrep message the right PCE.
JLLR: But how the PCE will have the
information?
One
additional quesion: is it suitable for the PCE to have such ability to
know exactly the destination domain it can compute towards?
JLLR: This is actually required. For
instance in an inter-AS case, an AS may be connected to multiple ASs,
and there may be multiple PCEs in this AS (e.g. ASBRs), each
responsible for computing path towards a given neighbord
AS.
Here
you said the neighboring AS, but not the destination AS.
It was an example
where the destination is located in the neighboring AS... But the same applies
when the destination is located
farther.
Thanks
JL
Some functions specified in the PATH-CAMP-CAP
sub-TLV are also defined in the PCEP, a clear division
should be made.
JLLR:
Actually, at the time being the PCEP spec does not define any
capability information.
In current PCEP spec, we only mention that
detailed capabilites could be carried in optional sub-TLVs of the Open
object (carried in the Open message).
But you are right such capability information may
be carried in PCEP.
The idea would be to carry simple
capabilities in the IGP and more complex capabilities in
PCEP.
Anyway I don't really see any issue if we define two ways to carry some
pieces of information:
-IGP-based capability discovery is useful for
PCCs that don't have a PCEP session with the PCE.
-PCEP-based capability discovery is useful when
IGP based discovery is not activated.
This sounds fine to
me.
Regards,
Zhang
Thanks for these
comments,
Regards,
JL
Cheers,
Zhang
Renhai
