[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on reliable accounting draft (was RE: StrawmanRADIUSEXT WG charter - Take Two)
I don't disagree on any of your points. I'd say that improving fail-over
behavior for RADIUS is not necessary at this point. However, as you have
previously noted, the retry behavior is something we should try to improve.
On 8/25/03 4:36 PM, "Bernard Aboba" <firstname.lastname@example.org> wrote:
>> In the case of a RADIUS "ping," a "good" result would certainly always be
>> true, while a "bad" result might be false (because it was delayed/lost in
>> proxy, etc.). So, if the goal is to determine if a server is available,
>> there might still be some value to this.
> As is noted in RFC 2865, such a "ping" doesn't provide much more
> information than attempting to send a RADIUS Request. For example, there
> is nothing that says that a NAS can't track responses from a RADIUS proxy
> in order to know whether that proxy is functioning. The problem is when
> the NAS doesn't hear anything for a period of time. Sending a "ping" all
> the way to the end server just adds traffic to the system; the NAS could
> just retransmit instead.
>> Of course, you could also specify
>> that a "ping" request MUST not be forwarded (but that may extend the scope
>> of the WG beyond what is reasonable and sensible).
> Such a "ping" would require a new command, and a fundmental change in
> proxy forwarding behavior. So it's probably out of scope for now.
> The question in my mind is whether *any* credible work on failover is
> possible without this level of change -- and whether even if the changes
> were made, they would be deployed. Most vendors have their own failover
> algorithms at this point, and I'd suggest that many would probably not
> choose to implement another one unless it was compelling.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.