On Jun 13, 2014, at 10:44 PM, Ted Lemon <[email protected]> wrote: > On Jun 13, 2014, at 4:27 PM, Brian E Carpenter <[email protected]> > wrote: >> It's prototype implementations and early deployments that will >> tell us the right answer, not further debate. > > Again, I didn't ask for "the answer." I asked for a description of what we > want in a routing protocol that isn't so prescriptive. There's a lot of > prescriptive stuff in there, and the reason that the particular paragraph you > are proposing we remove got added was to counterbalance it. E.g., why is > there a paragraph about all the routers knowing the whole topology of the > network? Maybe they will, maybe they won't, but why is it specified? If > we don't know what we want, this bit seems awfully specific. If we do know > what we want, why not say what we want? > > I think the right answer is to take out more text, but I'm not okay with just > taking out the particular paragraph you mentioned, or I would not have asked > for the working group's help on this. >
While I agree with Brian here, if you want more text out, so be it. Here's a proposal which does that, stopping short of trying to continue word-smithing the document at this stage. I simply took section 3.5 from -16, and removed sentences that seemed to me to be overly prescriptive, including the paragraph from Adrian. Ted, Is that good enough for you? Removed: Using information distributed through the routing protocol, each node in the homenet should be able to build a graph of the topology of the whole homenet including attributes such as links, nodes, connectivity, and (if supported by the protocol in use) link metrics. Routing within the homenet will determine the least cost path across the homenet towards the destination address given the source address. The path cost will be computed as a linear sum of the metric assigned to each link. The metric may be configured or automatically derived per link based on consideration of factors such as worst-case queue depth and router processing capabilities. The inclusion of physical layer characteristics including bandwidth, loss, and latency in path computation should be considered for optimising communication in the homenet. Homenets may use a variety of underlying link layer technologies, and may therefore benefit from being able to use link metrics if available. It may be beneficial for traffic to use multiple paths to a given destination within the homenet where available, rather than a single best path. Result: 3.5. Routing functionality Routing functionality is required when there are multiple routers deployed within the internal home network. This functionality could be as simple as the current 'default route is up' model of IPv4 NAT, or, more likely, it would involve running an appropriate routing protocol. Regardless of the solution method, the functionality discussed below should be met. The homenet unicast routing protocol should be based on a previously deployed protocol that has been shown to be reliable and robust, and that allows lightweight implementations, but that does not preclude the selection of a newer protocol for which a high quality open source implementation becomes available. Chown, et al. Expires December 12, 2014 [Page 28] Internet-Draft IPv6 Home Networking June 2014 The routing protocol should support the generic use of multiple customer Internet connections, and the concurrent use of multiple delegated prefixes. A routing protocol that can make routing decisions based on source and destination addresses is thus desirable, to avoid upstream ISP BCP 38 ingress filtering problems. Multihoming support should also include load-balancing to multiple providers, and failover from a primary to a backup link when available. The protocol however should not require upstream ISP connectivity to be established to continue routing within the homenet. Multiple types of physical interfaces must be accounted for in the homenet routed topology. Technologies such as Ethernet, WiFi, Multimedia over Coax Alliance (MoCA), etc. must be capable of coexisting in the same environment and should be treated as part of any routed deployment. The routing environment should be self-configuring, as discussed previously. Minimising convergence time should be a goal in any routed environment, but as a guideline a maximum convergence time at most 30 seconds should be the target (this target is somewhat arbitrary, and was chosen based on how long a typical home user might wait before attempting another reset; ideally the routers might have some status light indicating they are converging, similar to an ADSL router light indicating it is establishing a connection to its ISP). At most one routing protocol should be in use at a given time in a given homenet. In some simple topologies, no routing protocol may be needed. If more than one routing protocol is supported by routers in a given homenet, then a mechanism is required to ensure that all routers in that homenet use the same protocol. Chown, et al. Expires December 12, 2014 [Page 29] Internet-Draft IPv6 Home Networking June 2014 An appropriate mechanism is required to discover which router(s) in the homenet are providing the CER function. Borders may include but are not limited to the interface to the upstream ISP, a gateway device to a separate home network such as a LLN network, or a gateway to a guest or private corporate extension network. In some cases there may be no border present, which may for example occur before an upstream connection has been established. The border discovery functionality may be integrated into the routing protocol itself, but may also be imported via a separate discovery mechanism. Ideally, LLN or other logically separate networks should be able exchange routes such that IP traffic may be forwarded among the networks via gateway routers which interoperate with both the homenet and the LLN. Current home deployments use largely different mechanisms in sensor and basic Internet connectivity networks. IPv6 virtual machine (VM) solutions may also add additional routing requirements.
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
