Dear Den, Thanks for these useful comments on the PCEP FSM.
I'm bundling the answers: Comment 1: > In the description of the Idle state you can find: > > " - Initiates of a TCP connection with the PCEP peer, > - Increments the TCPRetry variable > " > > 1)This seems to be in contradiction with the definition of > the TCPRetry variable. > > 2)This variable can be only incremented in TCPPending state, > because only in that state it is possible to determine if > connection was established or not. You are right, the processing is not consistent with the definition. This will be updated in next revision. Comment 2: >The reception of an malformed message will be mentioned in OpenWait >and UP state, but not in KeepWait state. Why? This is an omission that will be rectified. Of course this applies to this state as well. Comment 3: > In the description of this state: > " > 2. If the proposed values are acceptable, the system adjusts its > PCEP session characteristics according to the proposed values > received in the PCErr message restarts the KeepWait timer and > sends a new Open message. If RemoteOK=1, the system > stays in the > KeepWait state. If RemoteOK=0, the system moves to > the OpenWait > state. > " > > If moving to OpenWait state OpenWait timer should be started > and not Keepwait timer. In the OpenWait state it will not be > waited for the expiration of the Keepwait timer. Actually the OpenWait timer has been started earlier. Here you send an Open, so you start a Keepwait timer. But I agree there is something missing. We need to process Keepwait/OpenWait timer expiration events both in Keepwait and OpenWait states. By the way that would actually be simpler to define a single timer to control session setup, as in BGP. Note that the FSM will be consolidated in rev 08, and this will account for your comments. Kind Regards, J-L _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
