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

[JP Vasseur <[e-mail]>]

Hi Lucy,

On Jun 22, 2006, at 12:17 PM, Lucy Yong wrote:

> Hi JP,
>
>
>
> Does that mean all PCCs and PCEs under one IGP? How about PCE  
> partitioning? Does a PCC get PCE announcement from only PCEs it  
> discovers, or from all PCEs within IGP.
>
>
>
> Looks like I miss something.
Yes.

Not sure how to help you there since the formulation of your question  
is quite confusing. Let me try to restate what I said: this ID  
defines a PCE discovery mechanisms based on IGP (compliant with the  
requirement ID on PCE discovery). All PCC and PCE acting as PCC will  
discover PCEs thanks to these IGP extensions wherever the LSA/LSP is  
flooded (see the ID for details).

JP.
>
>
> Best Regards,
>
> Lucy
>
>
>
> From: JP Vasseur [mailto:[e-mail]]
> Sent: Wednesday, June 21, 2006 7:08 PM
> To: Lucy Yong
> Cc: 'LE ROUX Jean-Louis RD-CORE-LAN'; 'Zhang Renhai'; [e-mail]
> Subject: 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:[e-mail]]
> Sent: Tuesday, June 20, 2006 1:54 AM
> To: Zhang Renhai; [e-mail]
> Subject: RE: [Pce] Comments on draft-ietf-pce-disco-proto-igp
>
>
>
> Hi Zhang,
>
>
>
> Please see inline,
>
>
>
> De : Zhang Renhai [mailto:[e-mail]]
> Envoyé : mardi 20 juin 2006 05:26
> À : LE ROUX Jean-Louis RD-CORE-LAN; [e-mail]
> 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 ; [e-mail]
>
> 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:[e-mail]]
> Envoyé : mardi 13 juin 2006 09:07
> À : [e-mail]
> 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
>
> [e-mail]
>
> https://www1.ietf.org/mailman/listinfo/pce
>
>
>
>

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