Re: Comments on reliable accounting draft (was RE: StrawmanRADIUSEXT WG charter - Take Two)

[Richard Perlman <perl@lucent.com>]

Bernard;

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.

Richard

On 8/25/03 4:36 PM, "Bernard Aboba" <aboba@internaut.com> 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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>