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

["Fred Baker (fred)" <[e-mail]>]

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.

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. 

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. 

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.