Re: [homenet] Updates to Homenet Architecture Principles doc

[Mark Townsley <[e-mail]>]

On Jun 13, 2014, at 10:44 PM, Ted Lemon <[e-mail]> wrote:

> On Jun 13, 2014, at 4:27 PM, Brian E Carpenter <[e-mail]> 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.