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