Not going to weigh in on what IGP. Following on bellow, it would be good to think about what we are looking for from the IGP. Link state, full topology view, sub-second convergence? Or reachability? And stability.
Independent of the choice of IGP, we still have to configure it, or recommend settings. john On 6/1/14, 9:07 AM, "Juliusz Chroboczek" <[email protected]> wrote: >> [...] IPv6, where routers communicate using link-local addresses. For >> what it's worth, Babel is quite able to establish adjacencies before >> addressing is up as well as in pure IPv4 networks. > >I've received a few questions about this by private mail, so please let me >lecture a little. The chairs will let me know if that's too much of an >off-topic for this list. > >Take a traditional single-stack routing protocol for IPv4, say RIPv2 or >OSPFv2: > > 1. your neighbour database is indexed by (interface, IPv4) pairs; > 2. your routes' next hops are (interface, IPv4) pairs. > >This means that you need to wait for an IPv4 address before you can do >anything. You can work around that by putting a (site-local) static IPv4 >on the loopback interface, but that involves some administrative overhead, >and hence is not applicable to Homenet. > >Compare this with an IPv4 routing protocol that is layered directly above >802.2, say a pure IPv4 implementation of ISIS: > > 1. your neighbour database is indexed by (interface, MAC) pairs; > 2. your routes' next hops are (interface, IPv4) pairs. > >Since MAC addresses always exist, you can establish neighbour >relationships >as soon as the interface is up -- no need to wait for global addresses to >be assigned. If you're link state, you can start flooding as soon as the >adjacency is up, which is pretty cool. However, since next hops are IPv4 >addresses, you still cannot route until both you and your neighbour get >assigned addresses. > >Now take the simple same single-stack protocol and port it to IPv6 (RIPng >or OSPFv3): > > 1. your neighbour database is indexed by (interface, link-local IPv6); > 2. your routes' next hops are (interface, link-local IPv6) pairs. > >If link-local IPv6 exist soon enough after the link is up, you get all of >the benefits of a stable neighbour identifier -- you establish adjacencies >and start flooding as soon as the interface is up and has a link-local >IPv6. In addition, since your next hops exist, you can start routing as >soon as the interface is up -- a big win if the address distribution >protocol is slow or unreliable. Finally, you don't need to do anything >special when you renumber, the next hops use stable identifiers. > >Consider now a double-stack protocol running over IPv6, such as Babel: > > 1. your neighbour database is indexed by (interface, link-local IPv6); > 2. your routes' next hops are (interface, link-local IPv6) or > (interface, IPv4) pairs, depending on the address family. > >Here, for IPv6 you're just like the previous case; for IPv4, you need an >address before you can route. The effect is that a Babel router starts >routing IPv6 as soon as the interface is up, but needs to delay installing >IPv4 routes until both neighbouring interfaces have an IPv4 address. In >effect, when the address configuration protocol has a hiccup, IPv6 routing >remains stable but IPv4 needs to reconverge. > >In summary, by running your routing protocol over IPv6, you get the >advantages of the ISIS approach, but in addition you gain: > > (1) the ability to run over GRE tunnels and OpenVPN in "tun" mode; > (2) much simpler implementation on Unix -- no need to use raw sockets, > just plain RFC 3493. > >What you don't get is the conceptual elegance of proper layering. > >-- Juliusz > >_______________________________________________ >homenet mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
