Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04

[Dave Nelson <[e-mail]>]

On Sat, Apr 6, 2013 at 3:28 AM, Peter Deacon <[e-mail]>wrote:

At some point the operator would have had to update firmware or software
> taking the system offline to obtain RADIUS/DTLS functionality.  These kinds
> of things are handled normally within a planned maintenance window.
>
> As draft points out in section 10.3 this automatic scheme causes breakage
> while there are multiple clients behind a single IP.  When just one of them
> upgrades all other clients break causing network outage and potential loss
> of revenue.  The simple manual server knobs without migration behavior in
> this case prevents migration from *causing* an outage.
>
> Having thought about this a bit more perhaps it would be better simply to
> move migration procedure from server to client.  This would fix NAT
> problems and server "flag" would only be used to declare level of security
> it is willing to accept.


I was wondering why starting up a replacement RADIUS server offering
RADIUS/DTLS on another IP address, and then switching the RADIUS server IP
address on each client as it's upgraded -- it has to be upgraded --
wouldn't accomplish the same overlapped, make-before-break transition as a
single server that supports two modes of operation?

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636