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 ?
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
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
