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

Hi,

On Jun 21, 2006, at 1:21 PM, Lucy Yong wrote:

> Hello JLLR,
>
>
>
> The draft covers various discovery requirements as mentioned in  
> section 4.2. Good work.
>
> Once thing I would like to get clarification is that the draft  
> focus on the discovery between a PCC and a PCE, a PCE and domains  
> that the PCE has visibility and can compute paths, and a PCE and  
> domains that the PCE can compute paths toward. The draft also  
> mentions that PCE information is disclosed to PCC.
>
>
>
> From these set of discoveries, I could not see if the discoveries  
> also include the discovery between PCEs and information changes  
> between PCEs. Maybe I miss them in context. Could you help to clarify?
>
>
yes it does. PCE originates IGP updates announcing their capabilities  
that can be processed by the PCCs or PCEs (acting a PCCs).

JP.
>
>
> Best Regards,
>
> Lucy
>
>
>
> From: LE ROUX Jean-Louis RD-CORE-LAN  
> [mailto:jeanlouis.leroux@orange-ft.com]
> Sent: Tuesday, June 20, 2006 1:54 AM
> To: Zhang Renhai; pce@ietf.org
> Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-igp
>
>
>
> Hi Zhang,
>
>
>
> Please see inline,
>
>
>
> De : Zhang Renhai [mailto:zhangrenhai@huawei.com]
> Envoyé : mardi 20 juin 2006 05:26
> À : LE ROUX Jean-Louis RD-CORE-LAN; pce@ietf.org
> Objet : Re: [Pce] Comments on draft-ietf-pce-disco-proto-igp
>
> Hi, Jean-Louis
>
>
>
> See inline, please.
>
> ----- Original Message -----
>
> From: LE ROUX Jean-Louis RD-CORE-LAN
>
> To: Zhang Renhai ; pce@ietf.org
>
> 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:zhangrenhai@huawei.com]
> Envoyé : mardi 13 juin 2006 09:07
> À : pce@ietf.org
> 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...
>
> 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
>
> _______________________________________________
> Pce mailing list
> Pce@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/pce