Re: [OSPF] [homenet] Egress Routing Discussion: Baker model

[David Lamparter <[e-mail]>]

also inline

On Fri, Feb 22, 2013 at 05:41:43PM +0000, Fred Baker (fred) wrote:
> inline 
> 
> On Feb 23, 2013, at 12:48 AM, David Lamparter <[e-mail]>
>  wrote:
> > For both "simple" and "full-blown" OSPFv3 the following loop/interop
> > mechnisms come to my mind:
> > 
> > 1. refusing adjacencies between SADR and non-SADR routers.
> >   Easily implemented with a Hello bit, this is the crowbar solution.
> >   Quite sufficient for homenet I guess, but probably less acceptable
> >   for anything else.
> > 
> > 2. flagging SADR support in router LSAs/LSPs.
> >   Provides enough information to avoid loops.  Three things can be done
> >   with this information:
> > 
> > 2a. install null/reject routes for paths that cross non-SADR routers.
> >     Provides adequate failure semantics, instead of looping packets
> >     around we get an ICMP unreachable.  Easy to implement.
> >     Downside: if there really is a non-SADR router, "not working" is
> >     now a state that is part of the result set of the dynamic route
> >     calculations.  Users (and admins) probably do not expect this.
> > 
> > 2b. calculate SPF around non-SADR routers
> >     Gets us a working network, but at a cost: there may now be 2
> >     different paths to reach some faraway router, one for SADR-routed
> >     packets and a different one for non-SADR packets.  Depending on how
> >     the router performs its SPF calculations, this can be hard to
> >     implement correctly - it's essentially a very narrowly and exactly
> >     specified case of multitopology routing.
> > 
> > 2c. on encountering non-SADR routers, figure whether they'll do the
> >     right thing with the packet.
> >     ... complicated and of questionable use IMHO.  Just listing this
> >     for completeness.
> > 
> > 2a and 2b can be mixed with each other; packets will get passed along by
> > 2a-type routers until they get discarded at a 2b-type router.
> > 
> > My personal opinion at this point is that 2a and 2b should both be
> > specified, with a requirement to indicate support level in the router
> > documentation.  We're unlikely to encounter normal OSPFv3 speakers in a
> > plain "production/final" homenet, so they could take the easy way.  If
> > this gets implemented on routers for enterprise use, I'd expect 2b
> > behaviour.
> 
> 
> So you want the non-SADR routers to implement a null route, and the
> SADR routers to route around the non-SADR routers.

No - sorry for not wording this clearly enough.

I want SADR routers to notice that they've hit a non-SADR router in
their SPF calculation.  And if they do, the SADR routers can either
install a null route (and keep topological sanity, flagging the route
under consideration down as "sorry no can do"), or go the alternate
topology way.

> I'm scratching my head on how the un-updated routers would know to
> install a null route if they don't understand the information.

They don't, indeed.

> I do think it would be straightforward to add a flag to the Hello
> indicating that they understand such updates, and refusing to neighbor
> with a router that doesn't. We have done that for other features. That
> does mean that adding a router to an area that understands the updates
> forces an update to all of the routers in an area, which could be a
> pain when upgrading. 

I think moving this flag to the router LSA is under all circumstances
preferable over this.  With the null route variant, it gives a painless
upgrading path that keeps plain-old destination routing working; SADR
can then be put into use when the relevant routers have the support.

> Setting a flag in the Router LSA indicating willingness to handle
> these routes is possible, but takes us in the direction of topological
> routing. My problem with approaching it as a topology is the implied
> management overhead; we need to know whether to include any given
> router or link in a given topology, and where we might have advertised
> topology-specific metrics in RFC 4915, we now want to infer that from
> a capability flag. ick. 

This is exactly why the SADR routers can instead go install a null
route, the only thing needed there is checking whether any router on the
calculated path doesn't support SADR.

FWIW, I think the double topology idea is not completely out of whack,
though admittedly complicated and complex.  The semantics are reasonably
well-defined, it boils down to bifurcating into exactly two topologies,
one normal and one SADR.  I'm not particularly keen or tacked down on it
though.


-David


P.S.: I can write this up in spec form if desired, I'm relatively new to
IETF and have no idea how this works and all.  Shall I put some text
together for the null route variant and throw it in here?  That would
as a side effect make it easier to evaluate the idea, I think.