{my comments before reading the ~170 messages on this thread.}
comparison> [Isn't it also the case that the HOMENET routing protocol will
comparison> be implemented on lower-end embedded devices, such as nodes in
comparison> a low-power wireless network? What is considered to be a
comparison> reasonable low-end system requirement for a HOMENET router? --
comparison> mrw]
As specified in the architecture document, section 3.5.1:
rfc7368> In this homenet architecture, LLNs and other specialised networks
rfc7368> are considered stub areas of the homenet and are thus not expected
rfc7368> to act as a transit for traffic between more traditional media.
So the gateway machine (the 6LBR) will run the HOMENET routing protocol and
the LLN routing protocol (RPL, or some other mesh-under protocol), but the
HOMENET routing protocol will never be run by the sensors.
The section 9, security consideration does indeed miss the mark.
Given that HNCP/DNCP would take care of "higher" identity and authorization
operations, and would produce some set of anchored credentials for the
routing protocols. the security question is not:
does the protocol support HMAC-FOOBAR.
The questions are rather:
1) how does the cost and convergence of the protocol change if security
considerations force the use of (secured 1:1) unicast for all messages
rather than multicast?
2) does the protocol include an asymetric method for authentication?
We know that multicast is hard to secure using symetric methods as all
parties involved can impersonate any other party. To what extent this is a
concern in homenet is not yet known, but on the other hand, in every
risk/cost/benefit analysis, if the cost of securing things is low enough,
it may make no sense not to...
In section 10, it is useful to know if multicast is supported; it is telling
that nobody has implemented multicast routing in ISIS. It would be
interesting to know how successful multicast routing is in other Link State
and Distance Vector protocols are. (Can Babel just include DVMRP for
instance? Why did nobody implement multicast for ISIS?)
A question which I did not see addressed is about debugging.
How easily can one (perhaps more capable, or having better management
interface) router give diagnostics about problems that might be occuring
elsewhere in the homenet?
Can one deal with broken/mis-having peer routers in a unilateral fashion?
(Consider the ability for parents to mitigate a dispute among technically
astute teenagers, while keeping both online)
Can one get diagnostics from just watching the traffic?
As much as we expect the network to be auto-tuning and auto-configuring and
self-healing; if people do get involved, which one is easier to understand?
{my comments after reading the thread}
Important things that I took out of the discussion:
1) Source address specific routing likely doesn't exist in some hardware.
My response is mostly: we often no idea what hardware can due to NDAs.
The movement (see netdev01.org conference this past week) is towards
having hardware which just lives under the linux kernel and its
configuration is transparent to "userspace"
2) Layer-2 aspect of ISIS.
> We didn't discuss the fact that Babel runs over UDP, while IS-IS runs
> directly over layer 2. This has a number of consequences, most notably
> related to ease of implementation, portability, and the ability to run
> over tunnels (say, GRE or OpenVPN in tun mode).
It also, btw, makes it unable to run over 15.4, since there is no ethernet
type. 6lo also has been defining ways to run IPv6/6lowPAN over other media
that have never seen IPv6. Probably doesn't matter as long as these are
really *LLNs*, but it could be that some of these technologies (802.15.4g has
much bigger packet sizes...) get used in new and unanticipated ways in the
IPv6 is dominant future.
3) metrics.
We don't know how we will assign link metrics, so we don't know how important
X-bit metrics are.
4) convergence over 802.11 MAC...
5) some amount of "my processor is slower than yours and still ran protocol XYZ"
(http://www.phespirit.info/montypython/four_yorkshiremen.htm)
6) discussion about multicast: do we even need it. With responses from
"nobody does it" to "we have 10^X customers" right now.
7) one comment was: "we need topology, so babel won't work for us."
8) some conversation about whether or not one can get link state for a wired
connection. I don't see that it matters: there could always be another
$9 layer-2 switch between the two routers. That's the problem with
layer-2 switching, we can't see it.
9) then there was a discussion of multiple (wifi) APs, how to either L2-mesh
them to
accomplish mobility, or to do L3-roaming by having stub versions of
homenet routing protocol and/or RIP.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
