Hi Jean-Louis,
Thanks for the reply. See inline for mine Best regards Fabien _____ De : LE ROUX Jean-Louis RD-CORE-LAN [mailto:[EMAIL PROTECTED] Envoyé : vendredi 7 septembre 2007 19:07 À : [EMAIL PROTECTED]; [EMAIL PROTECTED] Objet : RE: [Pce] PCEP Request ID Hi Fabien Thanks for your comment. Please see inline, _____ De : Fabien VERHAEGHE [mailto:[EMAIL PROTECTED] Envoyé : vendredi 10 août 2007 14:26 À : [EMAIL PROTECTED] Objet : [Pce] PCEP Request ID Hello all, I have a little comment/suggestion on PCEP regarding the request Id. In section 7.3.1 states that The Request-ID-number value combined with the source IP address of the PCC and the PCE address uniquely identify the path computation request context. I agree with that, however there may be 2 requests with same request Id exchanged on the same session in the case of session between 2 PCEs. One Path Request being sent by PCE#1 to PCE#2 and the other one by PCE#2 to PCE#1. I dont think there is any problem with that but I am a little concerned about potential misinterpretation especially in PCErr and PCNotif message. If a PCNtf/PCErr message contains an RP object, nothing indicates if it is related to the Request from PCE#1 to PCE#2 or the one from PCE#2 to PCE#1, except the notification/error type and value. I guess this is why for instance for the Pending Request cancelled notification there are 2 values. One for PCC and one for the PCE. Yes, this is exactly the reason why there are two values. So we would not need to define 2 values if the RP object fully identify the PathRequest. >From a protocol specification point of view it seems more straightforward to me. One of the problem, from an implementation perspective, is that we must first ready the Notification type/value in order to retrieve the correct PathRequest. Anyway, you have to parse the entire message. There are other implementations that first parse the whole message and then start processing the objects. This is IMO and implementation issue. I agree that it is partly an implementation issue. However, the implementation can be optimised if the RP object fully identifies the PathRequest. For instance, you would not need to decode the Error object if the PathRequest is unknown. Another problem is if an implementation does not recognize a given Error type/value, then it cant tell for sure which PathRequest it is related to. Anyway an Error related to a request is always sent in the PCE-PCC direction I agree this is true today but will it still be true with future PCEP extensions. If it is this a strict rules I think it should be mentioned in the draft. However cant we imagine that a PCC sends an Error message to a PCE because it does not like the Reply sent by the PCE? e.g. the Path does not respect the requested constraints. Besides we still that have a problem in case of unrecognised Notification type/value. So it seems to me it would be more consistent to add a bit in the RP object (in the flag field) to indicate the direction of the PathRequest. For instance if the bit is set the Message that carry the RP object is related to the request sent by the destination of the message. Hence, an RP object would actually uniquely indentifies a PathRequest. There maybe an ambiguity only in a few error/notif situations, and I don't think adding a generic bit would be really useful. By the way this would be a significant change wilth potentially new error situations to handle (what do you do if the direction PCC to PCE is set in a reply message?) . I dont really see it as a significant change. For the Error case I think it would be ok to say that the bit must be set in PCReq and Clear in PCRep message and must be ignored upon reception. Besides if we keep the RP object as is what do you do if you receive a PCNtf message with formatted as follows: <RP><Notif1><Notif2> with Notif 1 and Notif2 being pending request cancelled but one with Notification value 1 and the other with notification value 2. It seems this is anyway an error case that must be specified with current PCEP specification. Is that OK with you if we keep as is? So basically I agree that it is partly an implementation problem and that it is possible to do with current specification But it seems to me, from a protocol design point of view it would be more consistent if the RP object fully identify the PathRequest. Best Regards, JL Regards Fabien Verhaeghe
_______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
