Subject: RE : [Pce] WG feed-backs on PCEP

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Wed, 1 Jun 2005 20:20:02 +0200

Hi Zhang

Thanks a lot for these useful comments.

Please find below some inlined comments.

Regards,

JL

>-----Message d'origine-----
>De : [email-masked] 
>[mailto:[email-masked]] De la part de Zhang Renhai
>Envoyé : mardi 31 mai 2005 09:54
>À : JP Vasseur
>Cc : [email-masked]
>Objet : Re: [Pce] WG feed-backs on PCEP
>
>
>Hi, JP
>  Sorry for the late reply.
>
> What is used to identify the PCEs, IP address? it should be 
>better to give each PCE a sole ID, should a PCE have more than 
>one interfaces connected to the network.

Right actually the PCE is identified by an IP address.
For instance in case of a composite PCE, this could typically be a loop-back address that is always reachable.
We will clarify this point in next revision.

>
>In section 8.1, why OS, PR are defined to be two bits, 
>according the usage, one bit is enough, are there some other 
>thoughts on these definition?

You are right, currently one bit would be enough. 
We defined OS and PR fields with two bits to have flexibility for further usages.

>
> Section 9 only mentions the correlated request from the same LSR, but 
>the request from different LSR may also be considered 
>correlated, 

Such correlation of request sent by distinct PCCs would actually require quite complex procedures... 
And there is currently no specific requirement defined for such function.
Note that this first protocol version has been specified based on generic requirements defined in the PCE communication requirement draft. 
Our main objective here is to have a base spec and then work on application specific pieces in separate documents.
The multi-PCC request correlation procedure you mention, would have to be addressed later, in a separate document, if it appears that there are PCE applications requiring such feature.

>for example, the same source may be allocated by 
>different PCEs at the same time to different PCCs.

>
>About section 6:
>hello message:  this can be optional and can be decided by PCC 
>when PCC requesting a computation, for example, an object can 
>be defined that 
>inclueds the interval and timeout value and inserted into the 
>PCReq message, thus the hello message can be relative to PCReq 
>message, 
>if so, the hello message will have more meaning, for 
>example, it can tell PCC how long the request will be served, 
>this is especially useful when the PCReq is sent to multiple PCE. 

Actually hello message exchange would just be a heart beat to check PCC-PCE connectivity. Hence hello messages should not be relative to a particular PCReq. There would be no real gain, and this wouldn't not scale by the way...
Actually the functionality you mention is rather a notification, and this would be better achieved using the PCNtf message (For instance, we could define one or more optional TLVs of the NOTIFICATION object for that purpose).

>I think it is worst that PCE send the hello messages to all PCCs.

If you mean that it must be possible to activate/deactivate hello message exchange on a per PCC-PCE communication basis, then I agree with you. 
Note that the impact of such hello sessions would depend on the number of PCCs a PCE would communicate with, and on hello refresh intervals.
For instance I don't see any issue if a PCE maintains a hello session with 50 PCCs, with a 5  seconds hello refresh interval.

>
>detailed capability discovery:
>Before this is decided, all possible capabilities of PCE 
>should be estimated, maybe this will be clear after this 
>estimation.

I Agree. Note that some capabilities are already listed in draft-leroux-pce-discovery-reqs-00.txt, that will be updated soon.

>However, I have had some comments on this issue: 
>PCEs learn of each other's detailed capabilitis if 
>the discovery protocol can be used in PCE-PCE discovery, PCCs 
>learn of generic capabilitis, this will facilitate PCCs to 
>discovery PCEs. When the PCC's first request fails due to the 
>bad selection of PCE based on the generic 
>capability, the PCE determines the right PCE according to the 
>request and the acknowledge of  other PCEs' capabilities, and 
>also can communicate the detailed capabilities of the right 
>PCE though PCEP to the PCC.

Yes this is an option, the PCE discovery mechanism could be used only for discovery of some basic PCE capabilities, and PCEP would be used to discover detailed capabilities.

Again thanks a lot Zhang for these useful comments

Regards,

JL

>
>Regard,
>Zhang
>  
>----- Original Message ----- 
>From: "JP Vasseur" <[email-masked]>
>To: <[email-masked]>
>Sent: Thursday, May 26, 2005 11:42 PM
>Subject: [Pce] WG feed-backs on PCEP
>
>
>> Dear WG,
>> 
>> A new ID has recently been posted
>> (http://www.ietf.org/internet-drafts/draft-vasseur-pce-pcep-00.txt) 
>> proposing a new PCE communication protocol. There are 
>several aspects 
>> for which Jean-Louis, Eiji, Alia, Arthi and myself would be happy to 
>> get your feed-backs (see section 6). Comments are also very 
>welcome on 
>> the other parts of the ID of course.
>> 
>> Thanks.
>> 
>> JP.
>> 
>> _______________________________________________
>> Pce mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/pce
>
>
>
>_______________________________________________
>Pce mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pce
>

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