[c-nsp] Reliable static routes and 12.2S

[Andre Beck]

On Mon, Jan 31, 2005 at 04:52:41PM -0500, Rodney Dunn wrote:
> On Mon, Jan 31, 2005 at 10:45:50PM +0100, Gert Doering wrote:
> > On Mon, Jan 31, 2005 at 04:38:12PM -0500, Rodney Dunn wrote:
> > > For a DSL type environment you usually are not running
> > > a routing protocol over the links so what do you want
> > > to react?
> > 
> > Link status (or being able to tie static routes into BFD).
> 
> That's the one part I was thinking about was static routes.

Statics are better than nothing, but as I understood BFD, it is a
solution that could deal with connected routes as well, if not to
say it focuses on them.
 
> Link status is almost surely a no go.

But it would make things way easier. Of course this requires a
subinterface model, but as BFD is segmenting the anonymous broadcast
domain on top of which it is implemented into numerous point2point-
domains anyway, implementing that as subinterfaces is IMO the best
way to go. In reality you might want to have just one BFD domain
per broadcast domain, but this is application dependend. Ideally
the subinterface model would allow for point2point subinterfaces
that can be configured "ip unnumbered" for scalability and address
conservation.

In case of DSL, we are not actually speaking Ethernet, though. The
setup in question is ATM with per-PVC point2point subinterfaces that
run route-brigde encapsulation, one individual broadcast domain on
top of a SNAP PVC that is automatically terminated towards L3 using
that subinterface. We are running RBE because (and only because) the
ATM PVC is terminated at the customer end using a CPE (called modem,
but actually beeing a ATM/SNAP-PVC over DSL to Ethernet bridge) and
the CPE router is connected using Ethernet to that CPE bridge - the
resulting broadcast domain that contains but is not end-to-end an ATM
PVC (and thus cannot be OAM-managed end-to-end) is hopped using a
transit network that appears to the CPE router as any other transit
network on top of Ethernet, while to the CO router its is a RBE sub-
interface. Thus, BFD hits an entirely different architecture at the
CO end, with a per-customer subinterface already given and the "medium"
on which it has to operate beeing a dedicated RBE broadcast domain.
In this case, we are speaking of a connected route (because the sub-
interface is numbered) and getting this connected route to cease will
IMO require to Down that subinterface. It's simply the easiest way to
deal with it, and it is already working with OAM in the same context
anyway: When OAM cells cease to get answered, the subinterface goes
Up/Down and all connected or quasi-connected routes (statics with the
interface as destination) go promptly down as well, dynamic routing
protocols instantly learn the link has passed away, etc. So if you
ask me, downing the subinterface is the only consequent and consistent
way to deal with that at least in the ATM/RBE case, but depending on
how you actually implement it on shared media interface types like
(primarily) Ethernet, it would IMO make sense there as well. As I
already thought publicly, I'd like to think of BFD as an alternative
encapsulation (line protocol) that directly influences the way in
which the good old "keepalive" parameter is interpreted on the
interfaces configured with that encapsulation. That's a well known
and understood concept that already works with SLARP keepalives,
PPP LCP echo style keepalives etc - IMO BFD fits nicely there.

Also note that BFD on a ATM/BFD subinterface would have to be compa-
tible with BFD on Ethernet as this will be the typical COE/CPE combi-
nation in the DSL setups in question.

> > Just something to reliably notice that part of the "usual" something-
> > bridged-over-something-without-end-to-end-keepalives customer links
> > isn't working anymore, *without* having to run a full-featured routing
> > protocol with the CPE.
> 
> With statics I can see it.

But statics don't include connecteds, which are the typical means to
connect two routers over a broadcast domain. The basic idea is to notice
that a gateway that is supposedly direct connected actually is not there
anymore and get rid of the route that now builds a black hole. Of course
you might have the static route that points via the now dead gateway
disappear by some means like route tracking (making BFD another source
of tracking events would be an idea), but that's not as flexible as
the subinterface going down IMO. And it could be replaced by simpler
means like, say, tracking for the presence of a CDP neighbor.

> ie: default on the CPE with dial backup upon primary failure.

That's the idea. Which, consequently, requires detection of the dead
broadcast domain and switch to a backup route at both ends, COE as
well as CPE. It could be done a number of ways, but having a BFD
subinterface just magically go down and either a backup-interface
magically come to life or more distant statics float in would be
the least disruptive way to implement it - from the POV of the user
that means. It might of course be impossibly complex from a software
engineering POV, but I can't really imagine that, seeing how ATM
subinterfaces deal with OAM already.
 
> Issue would probably become scalability.

Isn't it always ;)

-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-