Re: [homenet] Updates to Homenet Architecture Principles doc

[Tim Chown <[e-mail]>]

Hi Ray,

As ever, good commentary.

On the 30 second thing, that was put in after discussion in a homenet session maybe 4-5 IETFs ago. As the text says, it is a “finger in the air number”, but the whole of that “but as a guideline…” part could be removed.

Tim

On 12 Jun 2014, at 22:20, Ray Hunter <[e-mail]> wrote:

> Here's my 2c worth on Section 3.5
> 
> I'm on record as preferring a "common Homenet routing protocol" without having any fingers in any particular choice.
> 
> I believe there is rough consensus around the choice of 0 or 1 routing protocol.
> 
> Going through Section 3.5 line by line.
> 
> 
>> 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.
> Fine by me.
>> 
>>   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.  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.
>> 
>> 
> Fine by me. Apart from the use of the word "graph" which could be overloaded or suggest a preference for link state protocols. s/graph/consistent view/ ?
>> 
>> 
>>   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.
> Fine be me.
>> 
>>   Routing within the homenet will determine the least cost path across
>>   the homenet towards the destination address given the source address.
> Too explicit IMHO. What is wrong with s/determine the least cost path across the homenet towards the destination address given the source address /maintain a loop free forwarding path between any given source address and destination pair/
>>   The path cost will be computed as a linear sum of the metric assigned
>>   to each link.
> Way too explicit IMHO. EIGRP is a perfectly good routing protocol that would be excluded by this requirement as the routing metric is a non linear sum of different individual link metrics, including minimum path bandwidth.
> Not that I'm urging use of EIGRP, but I don't see why it should be excluded on these grounds alone.
> 
>> 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.
>> 
> It's a may so fine by me.
>>   Multiple types of physical interfaces must be accounted for in the
>>   homenet routed topology. 
> Fine be me.
>> 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.
> Fine be me.
>> The inclusion of physical layer
>>   characteristics including bandwidth, loss, and latency in path
>>   computation should be considered for optimising communication in the
>>   homenet.
>> 
> Fine be me.
>>   The routing environment should be self-configuring, as discussed
>>   previously.  Minimising convergence time should be a goal in any
>>   routed environment,
> Fine by me.
>> 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).
>> 
> Way too explicit IMHO. I don't see why a figure of 30 seconds for convergence time is even given. I'm not happy to wait 30 seconds for video distribution over Homenet.
> Surely acceptable convergence time is a function of user expectations relative to the nature of the traffic being carried by the Homenet, combined with the available buffering before the user becomes aware of any topology change.
>>   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.
>> 
> Fine be me. But is totally inconsistent with the sentence above to always choose the shortest path. The "shortest path" may not be "the best" for all traffic. Again look at the concept behind EIGRP metrics, where high bandwidth traffic might be routed over a different route to latency sensitive traffic.
>>   At most one routing protocol should be in use at a given time in a
>>   given homenet.
> Definitely agree.
>> In some simple topologies, no routing protocol may be
>>   needed.
> Consistent with the 0 or 1 consensus.
>>  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.
>> 
>> 
> Fine be me. I'd rather just chose one, but this appears to me like trying to get a group consisting of more than one economist to agree on anything.
>> 
>> 
>>   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.
>> 
> Fine be me.
>>   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.
>> 
> Fine be me. It might be worth adding that we do not expect LLN network to act as transit networks between more traditional areas of the Homenet if you are going to revise the text anyway.
> 
> 
> Ray Bellis wrote:
>> 
>> Dear Working Group,
>> 
>> You may have noticed multiple revisions of draft-ietf-homenet-arch posted recently. After many iterations and a ton of work for our Editor In Chief, Tim Chown, all IESG “DISCUSS” positions have been resolved to either “Yes” or “No Objection”, with the exception of one “Abstain” from one of our Routing Area ADs who had requested that the following text be added to section 3.5:
>> 
>> “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 Chairs felt that the first half of this text was unnecessarily prescriptive for this document and did not reflect something the WG had achieved consensus on at this time.  We proposed a compromise that incorporated the latter non-normative half of this text in an earlier paragraph.  On the basis that we understood that this compromise had been accepted by the respective AD, the -14 revision was posted.
>> 
>> After -14 was posted and the AD’s position changed to "No Objection", we noticed that the above paragraph had inadvertently been included, in full, in addition to the latter half included as part of the proposed compromise! At the Chairs’ request, Tim removed the above paragraph in -15, which caused the AD to object as it appeared to him that his text was being removed after the fact.
>> 
>> Later today, Tim will be posting a -16 revision of the document that reinstates the above paragraph, in full, and removes the “compromise” text. On the basis that the new text is a potentially substantive change, our AD has requested that we put the document through one more Working Group Last Call to determine WG consensus on that issue.
>> 
>> In addition, one small change was introduced in the -15 revision based on WG feedback where a reference to Source Specific Multicast [RFC 4607] was introduced, but had not been called out explicitly in London or before. That change is as follows:
>> 
>> Old:
>>   It is desirable that, subject to the capacities of devices on certain
>>   media types, multicast routing is supported across the homenet.
>> 
>> New:
>>   It is desirable that, subject to the capacities of devices on certain
>>   media types, multicast routing is supported across the homenet,
>>   including source-specific multicast (SSM) [RFC4607].
>> 
>> The WGLC will commence immediately after the -16 is posted, and will last for two weeks.
>> 
>> We very much want your feedback here, but are not aiming to revisit the document in its entirety. As such, we would like to limit the scope of the WGLC to just the text quoted in this email.
>> 
>> Many thanks,
>> 
>> Ray and Mark
>> 
> 
> -- 
> Regards,
> RayH
> 
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet