Subject: [Pce] Contradiction in Idle state

From: [email-masked]
Date: Mon, 04 Jun 2007 14:43:14 +0200

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.

-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: [email-masked]
Date: Mon, 04 Jun 2007 16:43:09 +0200

The reception of an malformed message will be mentioned in OpenWait and UP state, but not in KeepWait state. Why?
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

---

From: [email-masked]
Date: Mon, 04 Jun 2007 17:29:59 +0200

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.
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Mon, 4 Jun 2007 19:36:40 +0200

Dear Den,

Thanks for these useful comments on the PCEP FSM.

I'm bundling the answers:

Comment 1:

> 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:

> 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