Subject: Re: [Pce] Question about PCEP Keepalive

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 7 Sep 2007 14:17:52 +0100

Hello?

Anyone got an answer?

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
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. So, surely
> the parameter in the Open object says how frequently the sender of the
> Open
> message wants to receive a Keepalive message. 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!
> 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.
>
> 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.
>
> Lastly, when describing that the use of keepalive is optional, there are a
> couple of points:
>
> 1. Optional should be an RFC 2119 word
> 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"
> 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.
>
> Yes?
>
> Adrian
>
>
>
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pce
>

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

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Fri, 7 Sep 2007 18:51:10 +0200

Hi Adrian,

Please see inline,

> -----Message d'origine-----
> De : Adrian Farrel [mailto:[email-masked]] 
> Envoyé : vendredi 7 septembre 2007 15:18
> À : [email-masked]
> Objet : Re: [Pce] Question about PCEP Keepalive
> 
> Hello?
> 
> Anyone got an answer?
> 
> Thanks,
> Adrian
> > sender that the session is open. It verifies for the 
> receiver. 

Yes

So, surely
> > 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
> > period the PCE may declare the session dead. This is no 

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.

> > determine the health of the session and cannot switch to a new PCE.

The PCC can reject the Open and start negociating...

> > recommended ratio of 3.5.

This is a good point

> > 1. Optional should be an RFC 2119 word

Right,

> >    that decides "whether it wants to receive keepalives"

Each peer takes part into the decision, this is a negociation.

> >    information. In this case, keepalive would not be needed.

OK, we will add this point. 

Regards,

JL

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 7 Sep 2007 19:16:09 +0100

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-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, September 07, 2007 5:51 PM
Subject: RE: [Pce] Question about PCEP Keepalive

Hi Adrian,

Please see inline,

Yes

So, surely
> > 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
> > period the PCE may declare the session dead. This is no

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.

This is a good point

Right,

Regards,

JL

---

From: JP Vasseur <[email-masked]>
Date: Fri, 7 Sep 2007 15:29:26 -0400

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.
>
> 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-masked]>
> 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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 8 Sep 2007 22:18:00 +0100

>> 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.
>>
>> directional and/or have very different timeouts in opposite  directions.
>
> 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 
> 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 ?

Not sure :-(

I think that the keepalive function is at the request of the speaker that 
wants to determine whether the session is alive. This is valuable to the PCC 
because it helps it select a PCE to which to send a PCReq. It is much less 
valuable for a PCE, but might be used to allow the PCE to discard dead 
sessions.

So, the PCE wants to be able to say to the PCC: "Don't bother sending me 
KA." Or maybe: "Only send me KA every 10 minutes". After all, the PCE does 
not want to be swamped with KA messages. Thus, it is important to give the 
PCE control of how often the PCC sends KA.

JL is right that this *can* be achieved using the Open from the PCC to 
propose the KA transmission frequency used by the PCC, followed by a PCErr 
from the PCE to "negotiate" the KA frequency, followed by a new Open from 
the PCC with the revised KA frequency. This is functional, but excessive and 
not very clever! The PCC does not care what KA frequency it uses so long as 
it is:
- acceptable for the PCE (that needs to receive the messages)
- not going to kill the PCC's CPU
So it is *far* more natural to allow the PCE to request the PCC's KA 
transmission timer on the PCE's Open message, reserving the PCErr for the 
unusual case.

In the other direction, the same thing applies. It seems that you want the 
PCE to simply announce its KA retransmission time, but this isn't good 
enough. A PCC that needs to know about session failures in a hurry will want 
a more rapid KA time and should be allowed to request it up front, rather 
than negotiate it using an error message.

The comparison with OSPF is a little ambiguous. The OSPF Hello message 
contains both the Hello Interval (how often the router will retransmit 
Hellos) and the Router Dead Interval (how soon the router will declare the 
adjacency dead if it does not receive a Hello - or another message). A 
router is expected to modify is own Hello Interval according to the received 
Router Dead Interval - that is, it is expected to behave as I suggest, not 
as you suggest.

Cheers,
Adrian

---

From: JP Vasseur <[email-masked]>
Date: Fri, 21 Sep 2007 17:37:15 -0400

Hi,

I think that we all agree that the end result is identical since we give
the opportunity for the PCEP peer to negotiate parameters during the
session set up.

What you're saying Adrian is that you find more natural for the PCC  
to "impose"
to the PCE the frequency at which the PCE should send KA to the PCC  
for the
PCC to get the failure detection time that it needs.

The reason why we choose the other way around is mainly driven by the
fact that we found not very natural to define a protocol where the  
PCC "imposes"
something to the PCE because it does not know the PCE's load (number of
already active PCEP sessions) and what it can afford to do in term of  
KA frequency.
The PCE could refuse but then we're back to the negotiation mode. By  
contrast,
with this mode, the sender who knows what it can afford to in term of  
KA frequency
is the one that decides of the frequency. In some very rare mode,  
this may not be
acceptable and there might be a round of negotiation during session  
establishment.

And of course, the PCC will make use of timer to resend its request  
in the
absence of reply within some period of time. The Keepalive is just  
there to
detect a PCE failure when the IGP discovery is not used or when the PCE
process failure does not trigger an IGP notification (used as a  
safeguard).

On the other comment (multiplier) the same thing apply. We want for A to
able to decide of the KA frequency but also the Deadtimer that B  
should use
"If you do not hear from me after the expiration of the DeadTimer,  
you can
declare the session down" because again A knows what it can guarantee
for the DeadTimer not B and this may greatly vary depending on the  
platform.

In other words, both modes have their own pros and cons, but I wanted  
to shed
some light on why we chose that approach.

Are we in sync ?

Cheers.

JP.

On Sep 8, 2007, at 5:18 PM, Adrian Farrel wrote:

>>> 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.
>>>
>>> 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.
>>>
>> 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 ?
>
> Not sure :-(
>
> I think that the keepalive function is at the request of the  
> speaker that wants to determine whether the session is alive. This  
> is valuable to the PCC because it helps it select a PCE to which to  
> send a PCReq. It is much less valuable for a PCE, but might be used  
> to allow the PCE to discard dead sessions.
>
> So, the PCE wants to be able to say to the PCC: "Don't bother  
> sending me KA." Or maybe: "Only send me KA every 10 minutes". After  
> all, the PCE does not want to be swamped with KA messages. Thus, it  
> is important to give the PCE control of how often the PCC sends KA.
>
> JL is right that this *can* be achieved using the Open from the PCC  
> to propose the KA transmission frequency used by the PCC, followed  
> by a PCErr from the PCE to "negotiate" the KA frequency, followed  
> by a new Open from the PCC with the revised KA frequency. This is  
> functional, but excessive and not very clever! The PCC does not  
> care what KA frequency it uses so long as it is:
> So it is *far* more natural to allow the PCE to request the PCC's  
> KA transmission timer on the PCE's Open message, reserving the  
> PCErr for the unusual case.
>
> In the other direction, the same thing applies. It seems that you  
> want the PCE to simply announce its KA retransmission time, but  
> this isn't good enough. A PCC that needs to know about session  
> failures in a hurry will want a more rapid KA time and should be  
> allowed to request it up front, rather than negotiate it using an  
> error message.
>
> The comparison with OSPF is a little ambiguous. The OSPF Hello  
> message contains both the Hello Interval (how often the router will  
> retransmit Hellos) and the Router Dead Interval (how soon the  
> router will declare the adjacency dead if it does not receive a  
> Hello - or another message). A router is expected to modify is own  
> Hello Interval according to the received Router Dead Interval -  
> that is, it is expected to behave as I suggest, not as you suggest.
>
> Cheers,
> Adrian
>
>
>
>