Hi Adrian,
On Sep 7, 2007, at 2:16 PM, Adrian Farrel wrote:
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.
Just to shed more light here ...
You could indeed reverse the logic but this would be equivalent to what
we have and in many cases it is more logical for the PCC to indicate the
frequency at which it will send KA rather then requesting the PCE to
send
KA at a certain frequency (there are circumstances in which it is not
desirable to proceed this way: the PCE may have a high number of PCEP
sessions opened, may just not want to dedicate too much resources
sending
hellos because the PCC wants to, ...). Note that it is quite usual to
proceed
with that logic (OSPF, ...). And as we said, there is a possibility
for the PCE
to request different parameters during PCEP negotiation.
Make sense ?
Cheers,
JP.
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
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
