As in the past, there was strong support for choosing a MUST
Implement routing protocol for all Homenet routers and that candidate
routing protocols must have an open source implementation available
that can be demonstrated to work in a Homenet alongside HNCP. There
was also strong support
On 11/18/14, 1:46 AM, Teco Boot t...@inf-net.nl wrote:
Op 17 nov. 2014, om 17:53 heeft Margaret Wasserman
margaret...@gmail.com het volgende geschreven:
On Nov 16, 2014, at 8:44 PM, Teco Boot t...@inf-net.nl wrote:
It could be long enough to get in trouble. There could be more than
two
so by my lights the thermostat has a simply astonishing amount
of flash (38MB), and an A8 class processor...
https://learn.sparkfun.com/tutorials/nest-thermostat-teardown-
Peeking at the board from the pics I cant see how much memory
it has, and the OS seems to be quite small (1.5MB) but I have
What feature of babel keeps traffic from looping during re-convergence?
Please see
http://www.pps.univ-paris-diderot.fr/~jch/software/babel/babel-20140311.pdf
slides 7 and 11-17. I'll be more than happy to clarify anything that's
not obvious from the slides.
-- Juliusz
Hi Juliusz,
I think I understand. If there is the potential for a loop (advertised
distance = babel router’s former distance), babel will wait for the next
sequenced route from the source. So, the loop-free guarantee is at the expense
of potentially faster convergence. Correct?
Thanks,
Acee
On Tue, Nov 18, 2014 at 7:33 AM, Acee Lindem (acee) a...@cisco.com wrote:
Hi Juliusz,
I think I understand. If there is the potential for a loop (advertised
distance = babel router’s former distance), babel will wait for the next
sequenced route from the source. So, the loop-free guarantee
I think I understand. If there is the potential for a loop (advertised
distance = babel router’s former distance), babel will wait for the
next sequenced route from the source.
Exactly.
So, the loop-free guarantee is at the expense of potentially faster
convergence.
In principle, yes.
I do note that the default 4 sec update interval bugs me.
It's probably the Hello interval that's biting you, not the Update
interval.
crank up the update interval by a factor of, say, 1, to see what
happens.
You cannot, Babel won't go below 10ms. (Hard-wired in the on-wire
encoding,
On Tue, Nov 18, 2014 at 4:12 PM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
I do note that the default 4 sec update interval bugs me.
It's probably the Hello interval that's biting you, not the Update
interval.
Sure.
crank up the update interval by a factor of, say, 1, to
On 16.11.2014 18:40, Pierre Pfister wrote:
Proposal #1 defines a new bit in the existing Assigned Prefix TLV, asking
neighboring nodes to inject the prefix in the routing protocol.
We could find other-but-similar ways to do it of course. Define a dedicated TLV
for instance. But I think this
On Mon, Nov 17, 2014 at 7:06 AM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
This is no different to how most routing protocols work.
Something of an aside to this conversation, but there is a similar
problem in dealing with an
external gateway that does not speak the routing
Something of an aside to this conversation, but there is a similar
problem in dealing with an external gateway that does not speak the
routing protocol either.
Aye.
The ¨babel-pinger¨ mechanism
http://lists.alioth.debian.org/pipermail/babel-users/2008-September/000160.html
would have
Isn't the Nest pinger just a shortcut for reducing the intervals and
validity times of the information transfer between the Nest-node and
the true-Homenet-node?
If I understand Dave right, the idea is to switch things around: instead
of having the Nest node speak a stub version of a Homenet
On Nov 16, 2014, at 8:44 PM, Teco Boot t...@inf-net.nl wrote:
It could be long enough to get in trouble. There could be more than two
neighbors, loaded wireless links and jitter (for collision avoidance) or loss
for routing packets.
Why would a stub network router be any different, for
As I understand it, it is not the idea of Proposal #1 to have a leafy
router, whatever that means.
The idea is that one (or more) of the battery-operated, low-power routers on
a low-power internally-routed network (like SEP nodes running RPL, or Nest
nodes), would choose a homenet router to
We also need to consider, in all of this, the fact that there _will be_
non-homenet-compliant routers and nodes on any home network where homenet is
newly deployed. We need to work properly with those routers and nodes, even
though they do not speak HNCP or whatever we designate as the
On Mon, Nov 17, 2014 at 9:20 AM, Henning Rogge hro...@gmail.com wrote:
On Mon, Nov 17, 2014 at 5:38 PM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
If I understand Dave right, the idea is to switch things around: instead
of having the Nest node speak a stub version of a Homenet
Dave,
At Nest, we have different OS platforms we use depending on the constraints
of the hardware.
For things like the Nest Learning Thermostat, where there is a graphics
subsystem and such, we use a $POSIX variant commonly found in larger
embedded systems. It has not much flash and even less
Juliusz,
you could also inject the route with a 3rd party next-hop pointing to L.
cheers,
Ole
On 16 Nov 2014, at 10:54 , Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
If the latter, I can see some opportunities for transient routing loops
if not done carefully. (And you
Ole Troan otr...@employees.org wrote:
1) pure peering - homenet - LLN ::/0
- LLN - homenet more specifics
for LLN routes and cloud service prefixes
I don't understand your ::/0 here.
I think the LLN gets a ::/0 route into the homenet, and the homenet gets a
specific route into
Michael,
1) pure peering - homenet - LLN ::/0
- LLN - homenet more specifics
for LLN routes and cloud service prefixes
I don't understand your ::/0 here.
I think the LLN gets a ::/0 route into the homenet, and the homenet gets a
specific route into the LLN. Is this what you were
for the pure peering case, I think it would be sufficient for the LLN
to do router discovery (as a host) and for the homenet to provide some
mechanism for the LLN to register which routes it should advertise for
it (aka buddy routing). that mechanism please inject these routes for
me, would
Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote:
non-optimal routing and brittleness. If the latter, I can see some
opportunities for transient routing loops if not done carefully. (And
you certainly don't want a routing loop on a link with low-power
nodes.)
Please
Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote:
If the latter, I can see some opportunities for transient routing loops
if not done carefully. (And you certainly don't want a routing loop on
a link with low-power nodes.)
That’s interesting. Could you try explaining
Henning Rogge hro...@gmail.com wrote:
This solves the issue of unexpected routing pathologies (the Homenet node
is participating in the native Homenet routing protocol, and hence
doesn't
introduce any new pathologies), as well as that of flash and RAM usage
(the
Nest node
Op 17 nov. 2014, om 17:53 heeft Margaret Wasserman margaret...@gmail.com
het volgende geschreven:
On Nov 16, 2014, at 8:44 PM, Teco Boot t...@inf-net.nl wrote:
It could be long enough to get in trouble. There could be more than two
neighbors, loaded wireless links and jitter (for
On Sat, 15 Nov 2014, Juliusz Chroboczek wrote:
Could you please clarify what you mean by inject a prefix in this
context? Stub router sends HNCP message to non-stub router asking it to
perform redistribution? When does the non-stub router cease
redistributing?
I was under the impression
I've thought about it some more this morning, and I've changed my mind:
I think it's actually not a bad idea, and if done right it might even work.
1) pure peering
- homenet - LLN ::/0
- LLN - homenet more specifics for LLN routes and cloud service prefixes
Ok. What I'm still not clear about
Le 16 nov. 2014 à 03:55, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr a
écrit :
I've thought about it some more this morning, and I've changed my mind:
I think it's actually not a bad idea, and if done right it might even work.
1) pure peering
- homenet - LLN ::/0
- LLN - homenet
Proposal #1 is the later. It’s probably the simplest way of doing it.
Could you please give a description of proposal #1 and how it works for the
general public here so we are all on the same level?
Thanks,
Steven
___
homenet mailing list
Le 15 nov. 2014 à 23:33, Mikael Abrahamsson swm...@swm.pp.se a écrit :
On Sat, 15 Nov 2014, Juliusz Chroboczek wrote:
Could you please clarify what you mean by inject a prefix in this context?
Stub router sends HNCP message to non-stub router asking it to perform
redistribution? When
Proposal #1 is the later. It’s probably the simplest way of doing it.
Could you please give a description of proposal #1 and how it works for the
general public here so we are all on the same level?
Sure,
See Mark’s mail which started this discussion. There is a pdf containing the
Sorry, missed the attachment ;)
Am 16. November 2014 18:40:07 MEZ, schrieb Pierre Pfister
pierre.pfis...@darou.fr:
Proposal #1 is the later. It’s probably the simplest way of doing
it.
Could you please give a description of proposal #1 and how it works
for the general public here so we
If the latter, I can see some opportunities for transient routing loops
if not done carefully. (And you certainly don't want a routing loop on
a link with low-power nodes.)
That’s interesting. Could you try explaining what could happen ?
I hope I'm just being paranoid, since I rather like
Op 17 nov. 2014, om 01:34 heeft Lorenzo Colitti lore...@google.com het
volgende geschreven:
On Sun, Nov 16, 2014 at 8:54 AM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
A and B are both announcing the LLN route. L crashes. A and B both
notice that L is no longer
On Sat, Nov 15, 2014 at 7:55 AM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
This included technical discussion around a partially unanticipated
I have always felt that we needed to have something that could route
packets as best as possible based on conditions (and in particular
requirement for HNCP to support a stub network with a gateway that
doesn't have sufficient resources to run a routing protocol.
Could someone describe what sort of resources these gateways (nest, I
assume) actually have? - What OS they run, how much ram and flash is
on them, is there virtual
On Nov 15, 2014, at 7:40 AM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
Mark, please scratch my previous offer to implement a stub-only variant of
Babel. Please let me know how much flash and RAM you give me, and I'll
do my best to fit Babel into that amount.
In the impromptu
In the impromptu meeting on Thursday, I believe that James Woodyatt said
that his nodes have 64K of ram and that code executes-in-place out of
ROM. He didn't say how much of that 64K is currently used for data for
other parts of the system.
A box with that little RAM should definitely be
On 11/15/14, 7:57 AM, Margaret Wasserman margaret...@gmail.com wrote:
On Nov 15, 2014, at 7:40 AM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
Mark, please scratch my previous offer to implement a stub-only variant
of
Babel. Please let me know how much flash and RAM you give me,
Since the assumption is that the device runs HNCP anyway, the intent is to
use that for the stub-only routing.
I'm probably just being slow, but I have trouble understanding how that's
supposed to work.
At some point, the stub network needs to be redistributed into the routing
protocol. Who
While we didn¹t spend a lot of time on it in Thursday¹s meeting, it was
proposed that the IoT device domain would never be used for transit so it
only needed to get a default (or other aggregate) and inject a prefix and
the HNCP could be made to satisfy this requirement.
On 11/15/14, 10:36 AM,
Sounds like HNCPs fallback-routing to me. But I am interested in reading the
minutes to see the details of that proposal.
Am 15. November 2014 21:44:47 MEZ, schrieb Acee Lindem (acee)
a...@cisco.com:
While we didn¹t spend a lot of time on it in Thursday¹s meeting, it was
proposed that the IoT
On Sat, 15 Nov 2014, Steven Barth wrote:
Sounds like HNCPs fallback-routing to me. But I am interested in reading
the minutes to see the details of that proposal.
My take from thursday session was that HCNP wouldn't be used for routing
at all. What HCNP would actually be used for would be
While we didn¹t spend a lot of time on it in Thursday¹s meeting, it was
proposed that the IoT device domain would never be used for transit so it
only needed to get a default (or other aggregate) and inject a prefix and
the HNCP could be made to satisfy this requirement.
Could you please
While we didn¹t spend a lot of time on it in Thursday¹s meeting, it was
proposed that the IoT device domain would never be used for transit so it
only needed to get a default (or other aggregate) and inject a prefix and
the HNCP could be made to satisfy this requirement.
Could you please
Mark Townsley m...@townsley.net wrote:
meeting slot the following day. This included technical discussion
around a partially unanticipated requirement for HNCP to support a stub
network with a gateway that doesn't have sufficient resources to run a
routing protocol.
I am
Mark Townsley m...@townsley.net wrote:
routing protocol. A technical solution was proposed and discussed
(proposal #1), using the attached slides. Proposal #2 in the
attached slide deck explored one way to support HNCP Fallback plus a
to-be-named Routing Protocol at the same
Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote:
This included technical discussion around a partially unanticipated
requirement for HNCP to support a stub network with a gateway that
doesn't have sufficient resources to run a routing protocol.
Mark,
Could you
Op 16 nov. 2014, om 05:43 heeft Michael Richardson mcr+i...@sandelman.ca
het volgende geschreven:
Mark Townsley m...@townsley.net wrote:
routing protocol. A technical solution was proposed and discussed
(proposal #1), using the attached slides. Proposal #2 in the
attached slide deck
50 matches
Mail list logo
