Hi Mark, participants to homenet WG,
I have some comments, FWIW.
Le 14/06/2014 10:04, Mark Townsley a écrit :
On Jun 13, 2014, at 10:44 PM, Ted Lemon <mel...@fugue.com
<mailto:mel...@fugue.com>> wrote:
On Jun 13, 2014, at 4:27 PM, Brian E Carpenter
<brian.e.carpen...@gmail.com <mailto:brian.e.carpen...@gmail.com>>
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 overlyprescriptive,
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
<http://tools.ietf.org/html/draft-ietf-homenet-arch-16#section-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.
Sounds as if there is no lightweight implementations high quality
open source of existing routing protocols?
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
Sounds as if current implementations dont do that?
is thus desirable, to avoid upstream ISPBCP 38
<http://tools.ietf.org/html/bcp38> 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.
Some deployments of IPv6 homenets with multiple IP subnets dont run
routing protocols, but static routing. I've discovered that recently
with much enthusiasm. Maybe it's just a first step, but I havent seen
documented this simple and numerous existing deployments.
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.
Ok.
Chown, et al. Expires December 12, 2014 [Page
29]
<http://tools.ietf.org/html/draft-ietf-homenet-arch-16#page-30>
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.
One simple mechanism to achieve it is to adiministratively assign
coherently the default route in all the routers. This may sound less
sophisticated than saying "discovery" but could work.
Maybe a simpler requirement would be a "default-route distribution
protocol", like in Router Renumbering, rather than a routing protocol
which includes a border discovery.
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.
This paragraph may read inconsistent by some reader (me).
I can see many sensors in home. But the power requirements are much
lesser than e.g. an outdoors deployments - indoors there is even IP over
220V (PLC) so power is plenty. There would be little reason to run an
LLN in home.
Additionally, I think virtual machines (like in virtualization, or jvm)
typically require much more power than real but small routers.
My two cents worth,
Alex
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
