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

From: David Lamparter <[email-masked]>
Date: Fri, 22 Feb 2013 12:48:22 +0100

On Fri, Feb 22, 2013 at 07:17:04PM +0900, Lorenzo Colitti wrote:
> On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter <[email-masked]> wrote:
> 
> > But given that route determination is a distributed algorithm, and that
> > Homenet devices will not always run the latest and greatest code,
> > what action should nodes that are running older code take regarding any
> > TLV options that they don't understand?
> >
> > Isn't there a danger that extensibility will lead to more routing loops,
> > instability, and black holes?
>
> Yes. If intermediate devices don't understand SADR, you can get routing
> loops. We should document that clearly and find out how to avoid it.

[quoting the earler loop sketch for convenience]
| If 4. is not given, this scenario will lead to a loop:
| All links assumed at equal cost, r2 does not support simplified SADR,
| R1,R3,R4 do.
|
| ISP_A, pfx_A ::/0             ISP_B, pfx_B, ::/0
|  |                            |
| R1 ------ r2 ------ R3 ------ R4
|  |
| Host
|
| Host now selects an address from pfx_B to reach some site on the
| internet.  R1 forwards to r2 because the ::/0 from R4 is more specific
| on the source.  r2 forwards back to R1 because it didn't consider source
| specific-ness and just went by lower cost...
[/quote]

Since I complained about this earlier, I feel obliged to throw possible
approaches around.  I'm excluding the prefix-assignment-integrated
approach to distributing SADR routing information since that would
supposedly by design require all participants to support SADR.

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.

(With the Baker OSPF/ISIS SADR specs quite independent from homenet as
they are right now, I think getting homenet-only solutions in those is
an unwise idea;  homenet optimisation possibilities like allowing
fallback to 2a on the other hand should be acceptable.)

-David

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 22 Feb 2013 17:41:43 +0000

inline 

> this gets implemented on routers for enterprise use, I'd expect 2b

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.

---

From: David Lamparter <[email-masked]>
Date: Sat, 23 Feb 2013 04:04:34 +0100

also inline

On Fri, Feb 22, 2013 at 05:41:43PM +0000, Fred Baker (fred) wrote:
> 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.