Re: [radext] configuration auto-discovery [was: draft-cullen-radextra-status-realm-00]

[Alan DeKok <[e-mail]>]

On Aug 13, 2023, at 2:23 PM, Bernard Aboba <[e-mail]> wrote:
> [BA] Before embarking on the design of a routing protocol (which is an IPR minefield and could generate lots of route flap traffic) it would first be useful to define use cases not already handled by dynamic discovery or existing failover mechanisms. Personally I have never encountered such a use case and have often disabled routing protocols on NAS devices to avoid route flaps.

  There are a few use-cases which could be solved.  A routing protocol may be the solution, or perhaps something simpler.

  One is that fail-over is just not defined at all in RFC 2865.   RFC 3539 defines a way to tell if a particular connection is alive.  But no specification describes how to fail over between connections, or load-balancing mechanisms, or how to address multi-hop issues.

  This lack means that any fail-over mechanism is largely implementation-defined.  Which means there are often connection / destination flapping, similar to route flaps.

  There is no way for a proxy to say "I'm alive, but I can't route this particular packet.  Please redirect it somewhere else".  Better connection signalling would solve that issue directly.  A routing protocol would solve it indirectly.

  Similarly, there's no way to signal capabilities.  RADEXT had long discussions about this a decade ago, with no conclusion.  The reverse CoA draft would directly benefit from some kind of connection or multi-hop signalling.  A routing protocol would help indirectly.

  The use of 7585 discovery helps here.  It's widely used in WBA OpenRoaming.  Roaming systems like eduroam are often "spoke and hub", but statically configured.  So perhaps a routing protocol is less useful there.

  But both solutions would benefit from clearer and more standardized fail-over, load-balancing, and discovery mechanism.

  Alan DeKok.