On Fri, Feb 22, 2013 at 07:17:04PM +0900, Lorenzo Colitti wrote:
> On Fri, Feb 22, 2013 at 6:52 PM, Ray Hunter <v6...@globis.net> 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
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
