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