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 <[email protected]> > 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. _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
