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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
