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
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
