Dear Fabien,
Thank you very much for your comments.
So if we accept a Keepalive message in OpenWait state, the problem is
solved. In such a case, I think we can also accept an Open message in
KeepWait state, which is mentioned in my fourth post.
If we agree on this, I think it is better to remove the following sentence
in Appendix A in order to let receiving those messages be an implementation
issue.
"In response to any other event the system releases the PCEP resources for
that peer and moves back to the Idle state."
Best regards,
Iksoon
_____
From: Fabien Verhaeghe [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 10:18 AM
To: 'Iksoon Hwang'; [email protected]
Subject: RE: [Pce] A case that never happens in OpenWait state
Hello Iksoon,
> we can have LocalOK=1 only when the system in KeepWait state receives a
Keepalive message from its peer
I guess your statement comes from the fact that the only place where it is
said to set the LocalOK variable to 1 is in keepwait state:
If a Keepalive message is received before the expiration of the
KeepWait timer, then the system sets LocalOK=1 and:
However if you apply the definition of the LocalOk variable you must set the
LocalOk variable to 1 each time you receive a positive acknowledgement
of the Open message, whatever is the current state (OpenWait or KeepWair).
LocalOK: the LocalOK variable is a Boolean set to 1 if the system has
received a Keepalive message acknowledging that the Open message sent
to the peer was valid.
More generally the state diagram described in PCEP draft must be carefully
interpreted because of the independent Open/Keepalive message flow in
opposite
direction which is managed with a single state.
But I agree that strictly speaking in the OpenWait state case there should
be statement about the receipt of a KeepAlive message when LocalOk is 0.
Best regards
Fabien
_____
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Iksoon
Hwang
Envoyé : mardi 9 décembre 2008 16:35
À : [email protected]
Objet : [Pce] A case that never happens in OpenWait state
Dear all,
Im currently working on a research project, called CARRIOCAS, which aims at
providing dynamically reconfigurable high speed network for high-performance
applications where PCEP is used for path computation. My work in the project
is to do modeling, validation, verification, and testing of PCEP. PCEP was
described in a formal language IF and some properties were validated. I have
some questions that were found during my work. The questions will be posted
in four separate emails including this one.
I found that there is a case that never happens in OpenWait state. Is there
anybody who can give me any advice if Im missing something? The detailed
case is as follows.
In Appendix A, when a system in OpenWait state receives an Open message from
its peer where no errors are detected, OpenRetry is 0, the session
characteristics are unacceptable but negotiable, and LocalOK=1, the system
restarts the OpenWait timer and stays in the OpenWait state.
According to our experiments, we found that the above case cannot happen. We
analyzed the reason and the result is as follows: we can have LocalOK=1 only
when the system in KeepWait state receives a Keepalive message from its
peer. Since the system can move to KeepWait state only after receiving an
Open message from its peer in OpenWait state, the OpenRetry value is always
more than 0 if we have LocalOK=1.
Thanks in advance!
Iksoon
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
