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
