Dear all,
I'm currently working on validation, verification, and testing of PCEP. PCEP
was described in a formal language IF and some properties were validated. I
have some questions and comments as follows.
1. A case that never happens
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, the above case never happens. We can have
LocalOK=1 only when the system receives a Keepalive message from its peer in
KeepWait state. Since the system can move to KeepWait state only after
receiving of an Open message from its peer in OpenWait state, the OpenRetry
value is always more than 0 if we have LocalOK=1.
2. Contradiction
In section 4.2.1,
Keepalive messages are used to acknowledge Open messages, and once the PCEP
session has been successfully established.
In section 6.2,
The PCEP session is considered as established once both PCEP peers have
received a Keepalive message from their peer.
In Appendix A,
If a system in OpenWait state receives an Open message from the PCEP peer
before the expiration of the OpenWait timer, it performs collision
resolution procedure. If there is no collision, no errors are detected in
Open message, and the session characteristics are acceptable to the local
system, the system:
o Sends a Keepalive message to the PCEP peer,
o Starts the Keepalive timer,
o Sets the RemoteOK variable to 1.
If LocalOK=0 the system clears the OpenWait timer, starts the KeepWait timer
and moves to the KeepWait state.
The statement in section 4.2.1 and starting of the Keepalive timer in
OpenWait state when LocalOK=0 are contradictory because the system starts
keepalive mechanism although the session is not established yet.
Also, there is another problem. In section 7.3, it is explained that "A
sends an Open message to B with Keepalive=10 seconds and Deadtimer=40
seconds. This means that A sends Keepalive messages (or any other PCEP
message) to B every 10 seconds and B can declare the PCEP session with A
down if no PCEP message has been received from A within any 40 second
period". The Keepalive timer should follow the Keepalive value in the Open
message that was sent to its peer (not the Keepalive value in the Open
message received from its peer). Therefore, the Keepalive timer can be set
only after the peer accepted the parameter values in the Open message. I
think the solution is to start the Keepalive timer and the Deadtimer when
the system moves to UP state (there is no explanation when a system should
start the Deadtimer).
3. The case of Error-Type=9, Error-Value=1 In section 7.15, If a PCEP peer
detects an attempt from another PCEP peer to establish a second PCEP
session, it MUST send a PCErr message with Error-type=9, Error-value=1.
In section 6.2,
Once the TCP connection has been successfully established, the first message
sent by the PCC to the PCE or by the PCE to the PCC MUST be an Open message
as specified in Appendix A.
Any message received prior to an Open message MUST trigger a protocol error
condition causing a PCErr message to be sent with Error-Type 'PCEP session
establishment failure' and Error-Value 'reception of an invalid Open message
or a non Open message' and the PCEP session establishment attempt MUST be
terminated by closing the TCP connection.
First of all, in such a case, do we have to try to establish the second
session in order to send a PCErr message to its peer? In order to send a
PCErr message it is necessary to send an Open message to its peer when a TCP
connection is established. Otherwise, sending of Error-Type=9 and
Error-value=1 will be useless because the peer will consider it as an error
from the other side.
Secondly, is it appropriate to ignore the second connection? In case of
connection oriented protocols, we may have resource mismatch problems, i.e.
one assumes that a connection is already released while the other is still
holding it. If the second connection is always ignored, we cannot have any
connection between two peers before resource mismatch problem is resolved.
4. Receiving Open message in KeepWait state According to the Appendix A, if
an Open message is received from its peer when the system is in KeepWait
state, the system should abort the establishment procedure. In order to have
a successful session establishment, in such a case, reply messages must be
sent in the order the requests are received. Isn't it too strong condition?
I'm sorry for too long questions and comments.
Thanks in advance!
Iksoon
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
