Thanks Jean-Louis,
You seem to be saying that the responder to an Open can use a PCErr to
define how often it wants to receive a Keepalive.
To me this is back-to-front and is likely to require additional message
exchanges. That is, if the PCE is configured to send infrequent Keepalives
(this is likely, because the default should be to keep the Keepalive traffic
low), the PCC must reject the Open message causing an extra message
exchange.
If the Open message says how often the sender wants to receive Keepalives,
then there is no negotiation to be performed.
I think this is more natural.
Note that I think it is a Good Thing (TM) that Hellos can be uni-directional
and/or have very different timeouts in opposite directions.
Adrian
----- Original Message -----
From: "LE ROUX Jean-Louis RD-CORE-LAN" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, September 07, 2007 5:51 PM
Subject: RE: [Pce] Question about PCEP Keepalive
Hi Adrian,
Please see inline,
-----Message d'origine-----
De : Adrian Farrel [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 7 septembre 2007 15:18
À : [EMAIL PROTECTED]
Objet : Re: [Pce] Question about PCEP Keepalive
Hello?
Anyone got an answer?
Thanks,
Adrian
----- Original Message -----
From: "Adrian Farrel" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, August 25, 2007 1:56 AM
Subject: [Pce] Question about PCEP Keepalive
> Hi,
>
> I'm looking at r08 sections 6.3 and 7.2.
>
> Section 6.3 has
>
> Note that sending Keepalive messages to maintain the
session alive is
> optional and PCEP peers may decide to not send Keepalive messages
> once the PCEP session is established.
>
> Section 7.2 has
>
> Keepalive (8 bits): maximum period of time (in seconds)
between the
> sending of PCEP messages. The minimum value for the
Keepalive is 1
> second. When set to 0, once the session is established,
no further
> Keepalive messages need to be sent to the remote peer.
>
> And also
>
> A sends an Open message to B with Keepalive=10 seconds and
> Deadtimer=30 seconds. This means that A sends Keepalive
messages (or
> ay other PCEP message) to B every 30 seconds and B can declare the
> PCEP session with A down if no PCEP has been received from A.
>
> I find this peculiar. Sending a keepalive message does not
verify for the
> sender that the session is open. It verifies for the
receiver.
Yes
So, surely
> the parameter in the Open object says how frequently the
sender of the
> Open
> message wants to receive a Keepalive message.
as currently specified the sender says how often it is ready to send
Keepalive messages
That is, how often the
> receiver of the Open message must send a Keepalive message.
>
> For example, if a PCC is worried that the session may fail,
it will want
> to
> operate the keepalive process. But as currently specified,
the PCC can
> only
> tell the PCE how often the PCC will send Keepalive
messages, and after
> what
> period the PCE may declare the session dead. This is no
help to the PCC!
But there is a negociation. As described in the FSM section, the PCC may
reject an open message with an unacceptable keepalive from the PCE, and
indicate an acceptable value in the PCErr message. So in this way the PCC
can control the frequency at which the PCE will send keepalive.
> If
> the PCE decides that it will not send Keepalive messages
then the PCC
> cannot
> determine the health of the session and cannot switch to a new PCE.
The PCC can reject the Open and start negociating...
>
> In other words, the keepalive process is back-to-front.
>
> Further, I don't see why you need the keepalive timer value
and the dead
> timer value. One value can be derived from the other,
probably through a
> recommended ratio of 3.5.
This is a good point
>
> Lastly, when describing that the use of keepalive is
optional, there are a
> couple of points:
>
> 1. Optional should be an RFC 2119 word
Right,
> 2. You need to make it clear that it is not the "PCEP peers"
> that decide to not send keepalives, but "each PCEP peer"
> that decides "whether it wants to receive keepalives"
Each peer takes part into the decision, this is a negociation.
> 3. You should indicate the circumstances surrounding
> the choice for this option. I think that, you might suggest
> that if PCE discovery is in use, the failure of a PCE can
> be speedily detected by the failure of the IGP, and can
> be flooded by timing out the LSA containing the discovery
> information. In this case, keepalive would not be needed.
OK, we will add this point.
Regards,
JL
>
> Yes?
>
> Adrian
>
>
>
>
> _______________________________________________
> Pce mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/pce
>
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
