Slides from the talk today are at
http://trac.tools.ietf.org/wg/homenet/trac/attachment/wiki/WikiStart/Homenet%20Routing.pdf.
I used them to lead a structured discussion of routing technologies
appropriate in Home and small Office (SOHO) networks, with a view to
requirements for selection of a routing protocol to "RECEOMMEND" (RFC 2119
language) that Homenet router vendors implement. This is in part to document a
discussion we had in the room and in part to lead it into list discussion.
As one might expect, a lot of the discussion was non-controversial. Points that
raised discussion started with the issue of multihoming as shown on slide 9. A
question arose on how multi-address interfaces work on typical operating
systems including Windows, MacOSX, and various Linux variants. It was observed
that rather than actually forming an address in each prefix as one would expect
in a multi-prefix network, Linux sees the various prefixes advertised in an RA
and selects one, forms an address in it, and uses that address until it
expires. Per RFC 4861, the lifetime on such a prefix is the same as the
lifetime on the IA_PD granted by the upstream network, which is generally on
the order of weeks. In the event that we have multiple routers to multiple
upstream networks each advertising a prefix and one fails - not just the link,
but the router and therefore the DHCPv6 server in it - the host will continue
using that prefix until it is actively rescinded.
A number of folks in the room had a discussion during a break about a related
scenario, and concocted the idea of an "RA Server"; if there are multiple
routers to multiple upstream networks and therefore advertising prefixes, one
of them should advertise all of the prefixes, and if the route to any given
prefix fails (including if the RA Server fails and another takes over the
function) should remove the prefix from use. In a network using OSPF/IS-IS, the
obvious router to perform this function might be the Designated Router.
After completing the slides, I made the following statement and opened it for
discussion: "If I were to make a call today, given the facts in evidence, I
would want a routing protocol with a high quality open source implementation
that was proven and documented interoperable with other implementations, and
which had the necessary characteristics to recover from failures in a period on
the order of tens of seconds to minutes as opposed to tens of minutes. I would
recommend either RIPng or OSPFv3, and recommend RPL for 802.15.4 interfaces."
Four comments/discussions came out quickly, and as near as I can tell
represented viewpoints common in the room.
1) why recommend a routing protocol at all?
I suggested that the probability of use of each of the scenarios on slide 4 were
single router network: 90th percentile
tree network: unusual
multi-router: perhaps 5th percentile
multihomed: unusual
The discussion in the room elevated the multi-homed case, due to corporate
information security requirements that required an employee's home office to
use a given network, the presence of TV-bearing and mobile telephone networks,
and so on. The argument for recommending any protocol at all has to do with the
zeroconf requirement and the interoperation requirement; if you actually have
multiple routers in the home, it would be nice if they could exchange routes.
2) Networks calling for other protocols
The room found the requirements of the Smart Grid HAN unconvincing. In summary,
the sense of the room was that one might sell a router that interfaced a RPL
network to an OSPF network in the rest of the home; ths might be in a special
purpose "interior" router, a function of the ESI, or on the CPE Router itself.
3) Why even bring up RIPng?
I bring it up because it is RIPv2 warmed over, and the majority of residential
routers I surveyed some months back support RIPv2; I expect it is an image
match to the expectations of companies that make consumer-grade routers, and
for simple scenarios works "well enough". That said, documents such as RFC 1812
recommend implementation of OSPF due to its characteristics with respect to
timing. The sense of the room favored implementation of OSPFv3 over RIPng, and
suggested that someone look hard at
http://tools.ietf.org/html/draft-dimitri-zospf with respect to prefix
management; one wants a well tested and proven-interoperable OSPFv3
implementation (with OSPFv3 itself at Draft Standard with respect to the
requirements of RFC 2026) that can also perform subnet prefix management.
There was discussion of a protocol profile; not only place all interfaces into
area zero by default, but remove the capability for multiple areas and
advertise the /64 allocated to RPL (if present) in an OSPFv3 type 9 record
along with the other prefixes on the router. How much of the implementation
could disappear (the LSDB would now only contain Router LSAs, Network LSAs, and
Prefix LSAs, and would only need to process those types) was indeterminate.
Using address families, this could also subsume IPv4 routing, although it seems
likely that since routers already support RIPv2, that routing would continue to
use RIPv2.
4) The use of OLSR in mesh network scenarios
Jim Gettys commented on the fact of OLSR use. The general sense of the room was
that OLSRv2 is interesting but out of scope for this discussion as mesh
networks are quite different from typical residential and SOHO networks.
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
