Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-igp

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Mon, 19 Jun 2006 10:23:52 +0200

Hi Zhang
 
Thanks for your comments
 
Please see inline,

________________________________

	De : Zhang Renhai [mailto:[email-masked]] 
	Envoyé : mardi 13 juin 2006 09:07
	À : [email-masked]
	Objet : [Pce] Comments on draft-ietf-pce-disco-proto-igp

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

	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.

	 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.
	 
	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. 
	 
	Thanks for these comments,
	 
	Regards,
	 
	JL 

	 
	Cheers,
	 
	Zhang Renhai

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: Zhang Renhai <[email-masked]>
Date: Tue, 20 Jun 2006 11:25:38 +0800

Hi, Jean-Louis

See inline, please.
  ----- Original Message ----- 
  From: LE ROUX Jean-Louis RD-CORE-LAN 
  To: Zhang Renhai ; [email-masked] 
  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,

----------------------------------------------------------------------------
    De : Zhang Renhai [mailto:[email-masked]] 
    Envoyé : mardi 13 juin 2006 09:07
    À : [email-masked]
    Objet : [Pce] Comments on draft-ietf-pce-disco-proto-igp

    Hi, all

    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, 

    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?

    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.

This sounds fine to me.

Regards,
Zhang 

    Regards,

    JL 

    Cheers,

    Zhang Renhai