Re: Comments on reliable accounting draft (was RE: Strawman RADIUSEXTWG charter - Take Two)

[Bernard Aboba <aboba@internaut.com>]

> 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/>