Hi Fabien,
Jumping at the end .... You wrote:
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.
As you know the only potential issue is in the case of two pending
requests with the same ID between two PCEs and the related potential
Notification messages. In that case, we do have the Notification
Value to
make sure that there is no ambiguity, as we did for the request
cancellation
Notification message. And if one of the PCEs does not "understand" the
Notification itself, then trying to determine the request it relates
to is
not relevant.
Agree ?
Thanks.
JP.
On Sep 10, 2007, at 4:07 AM, Fabien VERHAEGHE wrote:
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]
ftgroup.com]
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 don’t 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 can’t 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 can’t 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 don’t 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
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
