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