Subject: [homenet] Next Steps for Routing Protocol

From: Mark Townsley <[email-masked]>
Date: Fri, 14 Nov 2014 09:35:04 -1000

Our week in Hawaii was filled with lots of exciting and energetic
discussions. Ray and I have a very thorough set of minutes to sort through
and we will be posting these soon.

Our 30 minute time-slot for Routing Protocol Selection discussion turned
into 80 minutes, and continued in hallways, bars, and an ad-hoc 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.
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 time in a Homenet. Consensus among participants in the discussion here
in Hawaii was that Proposal #1 should be adopted. There was strong
consensus that we should not support Fallback Routing at all in HNCP, hence
Proposal #2 was rejected.

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 for setting a hard date, likely early 2015, to make a decision.

The two currently available routing protocols are IS-IS and Babel but at
this point there is no consensus on which is preferred, and other protocols
may emerge during the ongoing discussion.  Margaret Wasserman has
volunteered to work on a draft comparing the two. Factors that might affect
the decision include (but are not limited to):

- compatibility with RFC 7368, including support for source/dest routing
- specification maturity
- open source implementation maturity, diversity, and portability

There'll be more to follow over the next few weeks as and Ray and I cement
our thoughts in consultation with our AD on how we'll make an objective
decision that will reflect WG consensus.

Mark and Ray

---

From: Markus Stenberg <[email-masked]>
Date: Sat, 15 Nov 2014 10:44:32 +0200

On 14.11.2014, at 21.35, Mark Townsley <[email-masked]> wrote:
> Our 30 minute time-slot for Routing Protocol Selection discussion turned into 80 minutes, and continued in hallways, bars, and an ad-hoc 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. 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 time in a Homenet. Consensus among participants in the discussion here in Hawaii was that Proposal #1 should be adopted. There was strong consensus that we should not support Fallback Routing at all in HNCP, hence Proposal #2 was rejected.

At least judging by the slides, #1 is fallback routing with just extra TLV for RP-running nodes (and apparently the major benefit that it does not call itself fallback routing). The HNCP-only node has to do fallback-ish routes on anything it sees on the network anyway (see fallback routing description) or some wild default route that may or may not work always if HNCP-only node has also other routes outside the RP ‘cloud’.

> The two currently available routing protocols are IS-IS and Babel but at this point there is no consensus on which is preferred, and other protocols may emerge during the ongoing discussion.  Margaret Wasserman has volunteered to work on a draft comparing the two. Factors that might affect the decision include (but are not limited to):
> 

I suppose small footprint (both in terms of memory and flash) should be also a consideration. Given proposal #1’s wild success, everything that does not want to be strictly leaf/stub has to be able to run this.

Well, looking forward to the minutes.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 15 Nov 2014 16:55:49 +0100

> 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 please spell out the requirements for a stub-only
implementation?  Do you expect the stub router to hold the full routing
table, or just two routes (connected network and default route)?

Is there interest in a stub-only implementation of Babel?  Should it be
a standalone daemon, or should it be integrated in the HNCP daemon?

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Sat, 15 Nov 2014 08:46:03 -0800

>> 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
transport configuration information) across many disparate link layers
- homeplug, MoCa, 802.11, 802.11ad, 802.14, 6lowpan, VPNs, and sharks
with lasers. (https://twitter.com/RalfMuehlen/status/533414954167070720/photo/1
).

While full compliance with rfc2549 is not required, wires as we knew
them are going the way of the dodo, and already have, in most homes
and small businesses.

>> 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 memory, etc?

Are there devices in this category that can be hacked on? I am
reminded of the dnssec debate put to rest by merely producing a proof
of concept on an ancient cpe... I mean, babel, for example, is like,
61k, on mips with the sole dependency on libc. Other daemons, like
pimd are in the same size category.

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Dave Täht

thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 15 Nov 2014 18:40:25 +0100

> on them, is there virtual memory, etc?

Yes, that's perhaps a better approach.

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.

> I mean, babel, for example, is like, 61k, on mips with the sole
> dependency on libc.

I'm seeing 90kB on AMD64.  That includes three extensions to the core
protocol (source-specific routing, diversity routing, support for overlay
networks), but not the cryptographic MAC extension.

Memory usage is less than 100kB in typical deployments.  A (pessimistic)
upper bound on memory usage (not counting malloc overhead) in is given by

   (88 * neighbours + 48 * total_routers) * redistributed_prefixes

where a redistributed prefix is counted once per redistributing router
(e.g. two distinct edge routers redistributing the default route counts as
two).  This means that if you have a network with 100 routers advertising
400 prefixes, a router with 5 neighbours needs at most 200 kB of RAM.

I can see ways to optimise the memory usage even further (limiting the
number of fallback routes, tweaking the data structures), but my users
appear to be happy with the current performance, so I'd rather spend my
time elsewhere.

-- Juliusz

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 15 Nov 2014 07:57:23 -1000

> do my best to fit Babel into that amount.

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.

You have said that the Babel implementations have a sole requirement for libc, but I don't know if they also require Linux?  

My understanding is that the Nest boxes have their own mechanisms for routing between themselves, and that Nest does not plan to change that protocol for home deployments.  They are hoping that one or more of their units within a home deployment will be able to connect to a homenet network, providing access to the homenet without running a homenet routing protocol on all of their nodes or serving as a transit network for other traffic within the home.

I think you may see a similar requirement for SEP (Smart Energy Profile) nodes that run RPL for routing within a IEEE 802.15.4 low-power wireless network.  They will continue to route among themselves, but may want a way to attach their stub network to a homenet network.  Some of these nodes have similar capabilities to the Nest nodes that James has described.

> networks), but not the cryptographic MAC extension.

Are the current Babel implementations designed to execute-in-place out of ROM?
> 400 prefixes, a router with 5 neighbours needs at most 200 kB of RAM.

I don't know what numbers we are using to consider scaling for homenet networks.  Mark, are there back-of-the-envelope numbers for what we consider "a typical homenet" and a "largest possible homenet" that we could use to determine how much RAM Babel would be likely to use in those cases?

Margaret

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 15 Nov 2014 19:39:59 +0100

> 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 using filtering to avoid
growing its routing table.  Whether that is better done using stock babeld
with just two filtering rules or an ad-hoc daemon depends on how much
ROM/flash you can afford.

The point I'm making is that Babel has no link state database, so
filtering is all that's needed to ensure that your memory usage doesn't
grow -- there's no need for specific support for stub routers.  (That is
of course also the source of one of Babel's weaknesses -- you cannot
easily obtain the full topology of your network, which complicates
debugging --, but I think there's a saying somewhere about eating your
cake.)

> You have said that the Babel implementations have a sole requirement for
> libc, but I don't know if they also require Linux?

They need the sockets library (nothing fancy, just plain RFC 3493) plus
a reasonably simple interface to the kernel routing tables, currently
implemented for Linux netlink and BSD Unix.

The only non-portable assumption I am aware of is that for link-local
addresses sin6_scope_id is an interface index.

> Are the current Babel implementations designed to execute-in-place out of ROM?

We're speaking of plain C code with no dirty tricks, so there should be no
issues.  A small amount of hacking would be needed if they don't have malloc.

I'll try to get in touch with James Woodyatt to ask him for more details.

-- Juliusz

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 15 Nov 2014 20:15:25 +0000

On 11/15/14, 7:57 AM, "Margaret Wasserman" <[email-masked]> wrote:

>My understanding is that the Nest boxes have their own mechanisms for
>routing between themselves, and that Nest does not plan to change that
>protocol for home deployments.  They are hoping that one or more of their
>units within a home deployment will be able to connect to a homenet
>network, providing access to the homenet without running a homenet
>routing protocol on all of their nodes or serving as a transit network
>for other traffic within the home.
>
>I think you may see a similar requirement for SEP (Smart Energy Profile)
>nodes that run RPL for routing within a IEEE 802.15.4 low-power wireless
>network.  They will continue to route among themselves, but may want a
>way to attach their stub network to a homenet network.  Some of these
>nodes have similar capabilities to the Nest nodes that James has
>described.

Since the assumption is that the device runs HNCP anyway, the intent is to
use that for the stub-only routing.

Thanks,
Acee 

>I don't know what numbers we are using to consider scaling for homenet
>networks.  Mark, are there back-of-the-envelope numbers for what we
>consider "a typical homenet" and a "largest possible homenet" that we
>could use to determine how much RAM Babel would be likely to use in those
>cases?
>
>Margaret
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 15 Nov 2014 21:36:11 +0100

> 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 performs that redistribution?  The stub router?  One of the
neighbours of the stub router?  All of its neighbours?

-- Juliusz

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sat, 15 Nov 2014 20:44:47 +0000

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.

---

From: Steven Barth <[email-masked]>
Date: Sat, 15 Nov 2014 21:56:24 +0100

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)" <[email-masked]>:
>>> Since the assumption is that the device runs HNCP anyway, the intent
>is
>>>to

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 15 Nov 2014 22:06:17 +0100 (CET)

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 that the stub device 
would ask a homenet router (which participates in the routing protocol) to 
inject/redistribute routes on stub devices' behalf.

So HNCP wouldn't be used as a routing protocol, only configuration 
protocol.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 15 Nov 2014 22:15:37 +0100

> the HNCP could be made to satisfy this requirement.

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?

-- Juliusz

---

From: Ole Troan <[email-masked]>
Date: Sat, 15 Nov 2014 20:00:34 -0800

> perform redistribution?  When does the non-stub router cease redistributing?

indeed. there are quite a few unknowns here. on the Thursday meeting I think we jumped too early into making assumptions on solutions before understanding the requirements.

from speaking to James, I can at least see the variants for homenet to LLN peering:

1) pure peering
- homenet -> LLN ::/0
- LLN -> homenet more specifics for LLN routes and cloud service prefixes

2) peering + homenet numbered from LLN
3) peering + LLN numbered from homenet

as soon as there is a requirement for one of the networks providing prefix assignment to the other, some variant of HNCP is required in addition to some form of peering routing relationship.

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 most likely not require participation in a routing protocol, nor have stringent requirements for convergence, dead neighbour detection. we may possibly think of them more as static routes.

while 2 and 3 require participation in HNCP, my worry is that even HNCP is too chatty for the LLN to deal with. do we have any numbers? presumably one could design a stub HNCP, where the peer only received messages relevant to it, possibly even with a HNCP sleep proxy.

cheers,
Ole

---

From: Michael Richardson <[email-masked]>
Date: Sat, 15 Nov 2014 23:38:32 -0500

Mark Townsley <[email-masked]> 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 still skeptical that there isn't just a lot of fear for the cost of the 
simple announcement of the stub network.  I think that the announcement of a
stub network, where all outbound traffic goes to one or more announced
default routes, shoudln't be that difficult... 

Aside from security involvement (which I think is about HNCP anyway), I think
that it's just crafting a single packet to send out periodically.  Am I wrong
here?

    > The two currently available routing protocols are IS-IS and Babel but

I'm not complaining that OSPFv3 is not on the list, but I'm unclear why it
isn't there anymore.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Sat, 15 Nov 2014 23:43:07 -0500

Mark Townsley <[email-masked]> 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 time in a Homenet. Consensus

I think that the two things are not mutually exclusive, or did I mis-understand?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sat, 15 Nov 2014 23:46:25 -0500

> table, or just two routes (connected network and default route)?

Just two, I think.
(I think in the case of NEST that James spoke about, that it has a third
route via a tunnel to a walled garden in the cloud, but that's not our problem)

    > a standalone daemon, or should it be integrated in the HNCP daemon?

I think the most interesting thing would be reference code which implements
stub-only babel; does it even need to listen?    I think it would be clearer
as example code if it was not integrated, but in real life, I'd want it
integrated.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 16 Nov 2014 05:50:40 +0000

Right - the net is that the constrained devices need not run the chosen
routing protocol so we don’t need to be counting bits for this exercise.

On 11/15/14, 4:34 PM, "Pierre Pfister" <[email-masked]> wrote:

>Hello Juliusz,
>
>Please have a look at proposal #1 in the pdf Mark joined to this thread’s
>first mail.
>
>The idea is to use the existing Assigned Prefix TLV so that
>non-<insert-favorite-RP-here>-routers can ask neighboring
><insert-favorite-RP-here>-routers to inject 1-hop-away routes into the RP.
>The main difference with Fallback Routing based solution is that you
>don’t require all routers to implement fallback routing.
>
>Cheers,
>
>- Pierre
>
>
>Le 15 nov. 2014 à 11:15, Juliusz Chroboczek
><[email-masked]> a écrit :
>

---

From: Teco Boot <[email-masked]>
Date: Sun, 16 Nov 2014 08:34:42 +0100

> Op 16 nov. 2014, om 05:43 heeft Michael Richardson <[email-masked]> het volgende geschreven:
> 
> 

Having #2 for HNCP' SRI would be mandatory, for stability during transition periods.

Teco

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 16 Nov 2014 10:33:56 +0100 (CET)

> perform redistribution?  When does the non-stub router cease 

I was under the impression that HNCP had some kind of dead timer that 
would trigger if a node went away, and when this dead timer had triggered, 
redistribution would cease.

If this isn't the case, then I have no idea how it would work.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 16 Nov 2014 14:55:03 +0100

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.

> - LLN -> homenet more specifics for LLN routes and cloud service prefixes

Ok.  What I'm still not clear about is whether you intend the LLN prefix
to be announced by just one homent router, or by all of the homenet
neighbours of the LLN edge router.  If the former, you get 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.)

The other issue is how the edge router picks its next hop for its default
route.  I don't think that you'd want to reflect the routing protocol's
metric in HNCP, but you certainly need some way to avoid picking a badly
connected nexthop.  I see no easy solution here.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 16 Nov 2014 15:02:43 +0100

> stub-only babel; does it even need to listen?

Yes, it needs (1) to discover a default route and (2) to participate in
the request/response sub-protocol (by replying "I have no idea" to any
requests it gets).  Point (2) avoids a timeout when clearing a retracted
route from the network.

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Sun, 16 Nov 2014 08:33:43 -0800

> requests it gets).  Point (2) avoids a timeout when clearing a retracted

To add a little mental context, I have just been thinking about the link layer
problem in general, and that of encapsulation...

:

Another question is that Homenet Router X, needs some sort of wireless
dongle to talk to these devices (I expect it is not 802.11 we are
talking about here). So I imagine there is some sort of existing
dongle that has a linux driver to talk to?
Does it already work in openwrt? What kind of interface does it
present? That device does not have any power constraints,
and could for example (probably) talk to another router Y with the
same dongle elsewhere in the house....

....

I have been looking over some of these 16 bit microcontrollers for
another project, the advent of FRAM is quite useful (for high rad
environments especially) and the power consumption, amazing. They can
run off a coin cell battery for 5 years and I figure you can easily
solar power them, also.

http://en.wikipedia.org/wiki/TI_MSP430 - .1ua Ram retention!

But they seem to have no inherent wireless capability, except whatever
you could hook up over the SPI bus. The Xcore
stuff is neat, and there are a zillion arm mcus with various
capability, and I (still making assumptions here, as the
Thread group has not published any specs I have seen yet) figure this
is a 6lowpan-like layer we are talking about here?

Zigbee has a very small native packet size.
http://www.lsr.com/white-papers/zigbee-vs-6lowpan-for-sensor-networks

(bluetooth is also interesting perhaps?
http://www.ti.com/ww/en/wireless_connectivity/sensortag/index.shtml?DCMP=PPC_Google_TI&k_clickid=
)

Doing hnetd + a routing protocol over bluetooth could be useful in
context with solving the link layer problems more generally.

And a 16 bit arch would be kind of novel for us...

So... it is not useful to speculate further. While I think many IoT
devices are arm based, it would be nice to know what sorts of chips
they are using, and to get a look at the toolchain and OS. ? (/me
makes eyes at nest folk) (?)

The higher end of the IoT world is all linux it seems. (It seems
strange to be referring to things like the beaglebone black, raspberri
pi, and parallela as high end... Aside: has anyone played with a
galieo?

)

-- 
Dave Täht

---

From: Pierre Pfister <[email-masked]>
Date: Sun, 16 Nov 2014 07:27:08 -1000

Le 16 nov. 2014 à 03:55, Juliusz Chroboczek <[email-masked]> a écrit :

> neighbours of the LLN edge router.  

Proposal #1 is the later. It’s probably the simplest way of doing it.
But we can always find ways to agree on the buddy router using HNCP.
There is a DR election mechanism already.

> If the former, you get non-optimal

That’s interesting. Could you try explaining what could happen ?

> connected nexthop.  I see no easy solution here.

In the current design, a host selects the designated router as next hop, but there is nothing
which makes the DR be the best choice or not. A complication is that in multi-homed scenarios, 
the best next-hop may be different depending on the source-address you use.

Homenet is not chartered to modify the host. But I’ll try to think about how we could improve default router selection for hosts.

But to answer the question, I think Low-Power devices could configure as hosts (using RAs).

- Pierre

---

From: Steven Barth <[email-masked]>
Date: Sun, 16 Nov 2014 18:33:22 +0100

>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

---

From: Pierre Pfister <[email-masked]>
Date: Sun, 16 Nov 2014 07:37:05 -1000

Le 15 nov. 2014 à 23:33, Mikael Abrahamsson <[email-masked]> a écrit :

>> 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 that HNCP had some kind of dead timer that would trigger if a node went away, and when this dead timer had triggered, redistribution would cease.
> 

Yes, the idea would require the Low-Power to publish a route injection request in HNCP. HNCP is able to detect dead neighbors.
That means Low-Power devices would need to participate in HNCP, so the feasibility depends on how small the battery is.

We *really* need to clarify which kind of battery-operated devices we want to support. Because HNCP will be suitable for some, but not all of them.

- If the device can run HNCP -> Proposal #1 (or any other similar route injection using HNCP) would fit
- If the device can’t -> Define HNCP proxy mechanism… But I personally wouldn’t go there.

- Pierre

---

From: Pierre Pfister <[email-masked]>
Date: Sun, 16 Nov 2014 07:40:07 -1000

> 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 two proposals.

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 proposal is sufficient for the intended purpose.

- Pierre

---

From: Steven Barth <[email-masked]>
Date: Sun, 16 Nov 2014 18:41:44 +0100

Sorry, missed the attachment ;)

Am 16. November 2014 18:40:07 MEZ, schrieb Pierre Pfister <[email-masked]>:
>> 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,
>
>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 proposal is sufficient for
>the intended purpose.
>
>
>- Pierre

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 16 Nov 2014 19:54:50 +0100

>> 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 the idea of
redistribution through HNCP.

A and B are homenet nodes.  L is a low power node.

   A-----B
    \   /
     \ /
      L
      |
      |
     LLN

A and B are both announcing the LLN route.  L crashes.  A and B both
notice that L is no longer reachable, so each of them attempts to route
through the other one.  You have a transient routing loop that lasts until
A and B agree on the fact that L is unreachable.

On a wired network, the routing loop will be extremely short-lived (one
successful packet exchange for both Babel and OSPF, not sure about IS-IS).
I'm not sure what will happen on a wireless network, but I've learnt to be
pessimistic about the behaviour of 802.11.  I could imagine cases where
the looping data traffic prevents A and B from communicating successfully,
especially if L had more than just two Homenet neighbours.

In the case of Babel (or EIGRP, for that matter), running a stub
implementation on L solves the problem quite nicely, by allowing the
loop-avoidance algorithm to kick in before the loop is established.  With
link state, you still get a transient loop, but you're relying on the
carefully designed flooding algorithm of a mature routing protocol to
clear it, rather than counting on the poorly understood interactions
between the routing protocol and HNCP happening in the right order.

-- Juliusz

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 16 Nov 2014 14:34:26 -1000

> A and B agree on the fact that L is unreachable.

No, you have a loop that lasts for as long as it takes A to tell B that L
is no longer reachable, which isn't very long.

Specifically: for as long as A thinks that L is reachable via direct
connection, it tries to send packets to it directly and not through B,
which means there is no loop. As soon as it decides that L is not reachable
via direct connection, it stops forwarding and withdraws the route. Now
there's a loop, but as soon as B hears the withdrawal, it stops forwarding
to A, and the loop goes away.

This is no different to how most routing protocols work.

---

From: Teco Boot <[email-masked]>
Date: Mon, 17 Nov 2014 07:44:19 +0100

> Op 17 nov. 2014, om 01:34 heeft Lorenzo Colitti <[email-masked]> het volgende geschreven:
> 
> On Sun, Nov 16, 2014 at 8:54 AM, Juliusz Chroboczek <[email-masked]> wrote:
> No, you have a loop that lasts for as long as it takes A to tell B that L is no longer reachable, which isn't very long.

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.

Teco

> 
> Specifically: for as long as A thinks that L is reachable via direct connection, it tries to send packets to it directly and not through B, which means there is no loop. As soon as it decides that L is not reachable via direct connection, it stops forwarding and withdraws the route. Now there's a loop, but as soon as B hears the withdrawal, it stops forwarding to A, and the loop goes away.
>

---

From: Steven Barth <[email-masked]>
Date: Mon, 17 Nov 2014 09:32:43 +0100

> We could find other-but-similar ways to do it of course. Define a dedicated TLV for instance. But I think this proposal is sufficient for the intended purpose.

As its specced very vaguely some comments here based on the PDF and the 
various comments I found in the threads.

Simply creating default routes for IPv4 or IPv6 without checking whether 
you actually have such default routes in your homenet is a particularly 
bad idea. Similarly silently converting source-restricted to 
non-restricted routes is also not very clean and would probably break 
any possible mif efforts.

The designated router might be a bad choice as next hop if it lies on a 
path that doesn't have any uplink or the uplink with non-matching 
source-restrictions.

Also you need to revise your designated router election so that a 
leafy-router can never become the designated router. Depending on how 
you want to detect either one you probably need some sort of flag-TLV 
stating "I'm regular homenet router" - "I'm leafy homenet router" - "I'm 
no router at all".
In general you should think about whether flagging individual APs makes 
sense or if there is any case where you potentially want flagged and 
non-flagged APs, if not then generic "I'm leafy router" is probably a 
better idea.

Also creating this class of "leaf routers" could be problematic. At 
least it must be made very clear that these are NOT homenet-routers. 
Otherwise you end up having different "types" of homenet routers and you 
have one "type" that actually has worse properties than hierarchical PD, 
i.e. it cannot even work with other routers of the same "type" to form a 
tree topology.

Also do we potentially want these "leafy routers" to inject DPs into the 
homenet?

Cheers,

Steven

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 17 Nov 2014 11:28:34 +0200

On 17.11.2014, at 10.32, Steven Barth <[email-masked]> wrote:
> Also do we potentially want these “leafy routers" to inject DPs into the homenet?

At least in the Nest use case, apparently yes (but not one with default route)..

The more I read this thread, the more I think I should emphatize that when measuring run-time memory/traffic (=~ power consumption), given non-static network,

HNCP =~ random link state routing protocol > (some) distance-vector routing protocols.

Even if HNCP has some optimizations for traffic (mostly in the static network case), the memory footprint is still similar - O(# of total TLVs). Given that, you do NOT want to stick full implementation of that in a ’small’ device anyway, but instead have some sort of pub-sub ’sleep proxy’ or equivalent that requires small device to consume resources only to deal with things it cares about. Not the whole network state.

So, counter-proposal:

- HNCP + RP (TBD) for full router nodes
- HNCP-client (of some kind; basically TLV pub-sub with closest router(s) with full database) + RP (if small enough, see above) for small nodes; if the chosen RP does not fit the ‘small model’, then the extra hackery of routes and whatever tied to the HNCP-client connection lifetime or something may be needed

Case 1: DP provided by the ’small node’

Notably, the ’small’ node in this case _could_ provide e.g. DPs, and it’s own assignments there, but as it would not probably want to be running real PA algorithm either (due to power/memory consumption needs), it would have to provide the DP and it’s own assignments ‘as is’ (=higher priority than the dynamic choices).

Case 2: ’small node’ using home network

Probably simplest option here would be to have the ‘small node’ just run DHCPv6 PD(/DHCP) to get network access, and use static routes :-p

Case 3: (case 1+ case 2)

I do not think they are mutually exclusive so e.g. Nest’s ‘use home network to get connectivity, provide tunnel to own ULA to rest of home network’ should just work. And with this model, with much smaller footprint.

Finally, though.. Do we really want to account for this case? E.g. LLN networks usually have some beefy gateway that can talk number of protocols (and therefore has plenty of resources).

Cheers,

-Markus

---

From: Pierre Pfister <[email-masked]>
Date: Sat, 15 Nov 2014 20:00:06 -1000

> while 2 and 3 require participation in HNCP, my worry is that even HNCP is too chatty for the LLN to deal with. do we have any numbers? presumably one could design a stub HNCP, where the peer only…

We could try to make HNCP more Low-Power-friendly, but there will always be cases where HNCP will kill LP nodes because HNCP provides network-wide state synchronization (e.g. a buggy node keeps sending changing updates).

IMO, the reason why the ‘buddy’ approach was relevant for Low-Capacity devices like James’ is that HNCP could be useful for different things (e.g. advertise a Delegated Prefix), which we can’t really do with a routing protocol. So instead of having HNCP + RP, it would be HNCP alone. In which case the chattyness of HNCP doesn’t matter much. 

That said, I think the chatyness of both HNCP and the RP should be taken into account, as a ‘weak' requirement (i.e. it should not override already existing requirements).

Additionally, I **don’t** think the WG should consider defining an HNCP-proxying mechanism. If HNCP is successful, and if the need appears to be strong, OK. But we should make something that works without such support first.

- Pierre

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 17 Nov 2014 16:06:32 +0100

> This is no different to how most routing protocols work.

(I think you meant "most link-state routing protocols".)

Yes, to a certain extent.  But now we have two distinct routing
protocols -- HNCP and the "real" routing protocol --, which have different
flooding protocols, with different timers and different resiliency.

As I've said, I am hopefully just being paranoid, but my gut instinct is
that this sort of two-way redistribution must be done with care.

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Mon, 17 Nov 2014 07:47:01 -0800

>> 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 protocol either.

In my case (this morning) I had a cable modem that supplied IPv4 IPs
and a default route, but resolutely
decided it wasnt going to forward packets, while I had another cable
modem on a different router,
farther away that was working properly. The ¨babel-pinger¨ mechanism

http://lists.alioth.debian.org/pipermail/babel-users/2008-September/000160.html

would have been a cure for this...

... had I actually had it compiled.

A Nest-pinger (or responder - ) might be a way to keep a route alive....

-- 
Dave Täht

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 17 Nov 2014 17:07:19 +0100 (CET)

> that this sort of two-way redistribution must be done with care.

I am not sure we need two-way redistribution. The LP device could learn 
default route through RAs just like any host, and HNCP would only be used 
to inject into routing protocol, not the other way around.

Apart from that, I agree that one shouldn't do two-way redistribution, but 
I don't see why that would be needed.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 17 Nov 2014 17:08:18 +0100

> problem in dealing with an external gateway that does not speak the
> routing protocol either.

Aye.

> The ¨babel-pinger¨ mechanism
>

I had forgotten this hack.

> A Nest-pinger (or responder - ) might be a way to keep a route alive....

You're completely right, Dave.  This would solve the issue with minimal fuss.

-- Juliusz

---

From: Henning Rogge <[email-masked]>
Date: Mon, 17 Nov 2014 17:15:17 +0100

> You're completely right, Dave.  This would solve the issue with minimal fuss.

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 you want to discover a link loss quickly, just exchange data more
often to make sure the other side is still there. Doesn't matter if
its a ping, a HNCP packet, a BABEL packet or a layer2-beacon.

Henning Rogge

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 17 Nov 2014 17:38:23 +0100

> validity times of the information transfer between the Nest-node and

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 protocol, you
have a specialised Homenet node that speaks a degraded version of Nest's
protocol (just like a babel-pinger node speaks both Babel and a degraded
version of DNS).

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 isn't running any new software).  It does cause sub-optimal
routing, though, unless the specialised node is at the right place in the
network.

-- Juliusz

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 17 Nov 2014 06:53:49 -1000

> 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 this, than any other router?  Are we likely to run into these problems whenever a router that is connected to more than one peer goes away?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 17 Nov 2014 07:02:35 -1000

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 proxy for the low-power network.  The homenet router (not some "leafy router", just a regular homenet router) would inject routes for the low-power network, would serve as the default up-link router for that network, and would route packets destined for the prefixes on the lower-power link down into the low-power network.  None of the low-power nodes would run the homenet routing protocol.  This is not unchartered territory, as routers running OSPF would often do this sort of thing for networks running RIP, back in the day, and BGP routers still do this for networks running OSPF or IS-IS.

In cases where a low-power network has a gateway that _is_ capable of participating in the homenet routing protocol (whether it is IS-IS, Babel or something else), that gateway will just be a normal homenet router and will route to/from the low power network itself.

Margaret

On Nov 16, 2014, at 10:32 PM, Steven Barth <[email-masked]> wrote:

> As its specced very vaguely some comments here based on the PDF and the various comments I found in the threads.
> 
> 
> Simply creating default routes for IPv4 or IPv6 without checking whether you actually have such default routes in your homenet is a particularly bad idea. Similarly silently converting source-restricted to non-restricted routes is also not very clean and would probably break any possible mif efforts.
> 
> The designated router might be a bad choice as next hop if it lies on a path that doesn't have any uplink or the uplink with non-matching source-restrictions.
> 
> Also you need to revise your designated router election so that a leafy-router can never become the designated router. Depending on how you want to detect either one you probably need some sort of flag-TLV stating "I'm regular homenet router" - "I'm leafy homenet router" - "I'm no router at all".
> In general you should think about whether flagging individual APs makes sense or if there is any case where you potentially want flagged and non-flagged APs, if not then generic "I'm leafy router" is probably a better idea.
> 
> Also creating this class of "leaf routers" could be problematic. At least it must be made very clear that these are NOT homenet-routers. Otherwise you end up having different "types" of homenet routers and you have one "type" that actually has worse properties than hierarchical PD, i.e. it cannot even work with other routers of the same "type" to form a tree topology.
> 
> Also do we potentially want these "leafy routers" to inject DPs into the homenet?
> 
> 
> 
> Cheers,
> 
> Steven
>

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 17 Nov 2014 07:08:46 -1000

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 homenet routing protocol.

Margaret

---

From: Henning Rogge <[email-masked]>
Date: Mon, 17 Nov 2014 18:20:48 +0100

> protocol (just like a babel-pinger node speaks both Babel and a degraded

yes.

> routing, though, unless the specialised node is at the right place in the

If Homenet assume any "lightweight nodes" (e.g. a Nest node) speak IP,
then using ICMP might be an easy way to do this.

If the node does not speak anything beyond its own protocol, I agree
it would need a special piece of code in the Homenet node.

Henning Rogge

---

From: Steven Barth <[email-masked]>
Date: Mon, 17 Nov 2014 18:32:43 +0100

> 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 t…
We already do:

HNCP-02 can be used behind legacy CERs that offer DHCPv6-PD (e.g. hipnet).
Also HNCP-02 states:

    A homenet router SHOULD provide basic connectivity to legacy CERs
    [RFC7084  <http://tools.ietf.org/html/rfc7084>] connected to internal interfaces in order to allow
    coexistence with existing devices.

which is funny enough a more lightweight (DHCPv6-PD-based) version of 
the R-Flag described in proposal #1 but not requiring the constrained 
device to speak HNCP (and maintain its full link-state database).

>> As I understand it, it is not the idea of Proposal #1 to have a  "leafy router", whatever that means.
A leafy router in this context is a router running HNCP but not the 
homenet IGP.

>> 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 p…
Well HNCP itself maintains a link-state database in order to allow 
algorithms like prefix delegation to run fully distributed. Proposal #1 
proposes to make constrained routers run the full HNCP, i.e. requiring 
them to maintain the full link-state. Given Babel as a distance-vector 
protocol (given reasonable implementations) your IGP probably requires 
less ressources than HNCP itself. Plus as Juliusz demonstrated you can 
actually make small stub-versions of them.

So in most cases what you actually need is a stub-version of HNCP, i.e. 
a pubsub-like protocol a constrainted device can talk to an HNCP router 
in order to publish / subscribe to its link-state DB. This would work a 
bit similar to how we hook DHCPv6-PD to HNCP as described earlier.

Once you have that you can think about whether you want to do a 
route-injection using HNCP like "proposal #1" and "fallback-routing" or 
a stub-implementation of the routing-protocol as noted earlier.

Cheers,

Steven

---

From: Dave Taht <[email-masked]>
Date: Mon, 17 Nov 2014 10:03:31 -0800

yes.

> it would need a special piece of code in the Homenet node.

We are still quite in the dark about what we are dealing with here,
and while the
speculation is fun, it would be nice to truly grok the hw, code and ideas we are
dealing with.

My understanding of sensor networks is that they boot, request an address,
and then periodically wake up to announce a bit of data - ¨The temperature
where I am is now is 34C¨ - or ¨my address is about to expire, please tell
me a new address in exactly 200ms when I am awake again¨ and
¨The window is open¨.

The mere act of announcing a bit of data should be enough to refresh the
route (or nd/arp?) table on the listening homenet router(s). The
problem still remains
of how to do address assignment to boxes that are not connected most
of the time, and the problem of finding the right node to be the default gw
for the sensor network as a whole (assuming it is also doing meshy routing
itself) remains...

As for address assignment I generally do p2p /128 routes...
(This is something I basically do already with AHCP, distributing p2p
 routes out of a dedicated IPv6/64 subnet)

As for a homenet house, consider the following topology

(If you have a mail reader with proportional fonts, I also
stuck this up at: http://pastebin.com/1dfgtbp1 )

               R1|  -  - -   N0 Motion detector
                / \          N9 weather station
               /   \
              /     \
             /       \
            /         \
           /           \
          /             \
  _______/_______________\____________
 |                     |      R2      |
 |      N1             |              |
 |                     |              |
 |_______________N2____|_____________ |
 |          |                         |
 |   R3     |              N3         |
 |          |                         |
 |          |                  N6     |
 |__________|_________________________|
 |                |                   |
 |                |              N7   |
 |                |                   |
 | N5             |                   |
 |                |              N8   |
 |________________|_R4______________CM| -----> (Internet)

CM is a cable modem connecting R4 to the internet.

R1, R2, R3, R4 are homenet routers, connected up every which way.
R1 and R2 cannot directly reach R4.

Nx are devices using whatever the heck protocol is connecting these
sensor boxes together.

(lest you think this is a contrived example, this is exactly the
 house armory.com has)

Now, in this example, N1 can get to N8 and then R4 via its own protocol
(probably), but a more robust and reliable method would be N1, N2, R2,
R4, or it might be N1, R3, R4.  But N0 needs to talk to R1 as everything
else is too far away, and it is entirely likely that a more direct path
from N1 to N2 OR N5 is blocked by a fireplace ...

IF R1-R4 are all bridged together then things are possibly simpler,
but different. I would imagine that all homenet routers would
broadcast and receive packets from Nx in the hope that one or more
would reach the right device.

If they are all routed...

As IPv6 addresses as distributed by certain providers
are limited, a dedicated ipv6 subnet with p2p /128 routes, and
whatever device had the best (signal strength?) should be
the default gateway for it...

So... how is a Nx network supposed to work with areas
of disconnectivity? Range extenders?

-- 
Dave Täht

---

From: James Woodyatt <[email-masked]>
Date: Mon, 17 Nov 2014 12:23:29 -0800

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 memory.  We cut a
lot of things out to make everything we need to fit, and we feel
significant volatile and non-volatile memory pressure on this platform.

For things like the Nest Protect, which are much smaller, we use a
library-oriented $RTOS variant.  The current Nest Protect device, for
example, executes code from 512 kB of flash, using 64 kB of RAM.  It has a
very lightweight IPv6 stack, over which we have implemented all our
communications protocols and our application logic.  We are under truly
extraordinary memory pressures on this platform, of the sort that I believe
only somebody with experience working in the C64 demoware scene can fully
appreciate. (Seriously, you can't even. Don't try.)

I'm hoping future evolutions both in these product lines might have
incrementally more resources, in which it may be possible to demand space
for Comms Engineering to insert HNCP, when it's finally deployable.
Assuming HNCP can be made to work. Lot of ifs. However, whatever happens,
we eventually will need something that does what HNCP does, and I like HNCP
itself better than I like the idea of rolling something proprietary.

Does that help explain matters?

On Sat, Nov 15, 2014 at 8:46 AM, Dave Taht <[email-masked]> wrote:

> with lasers. (
> https://twitter.com/RalfMuehlen/status/533414954167070720/photo/1
> ).
>

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Nov 2014 12:57:30 -0800

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 <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Nov 2014 16:14:15 -0500

Ole Troan <[email-masked]> 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 the LLN.  Is this what you were trying to say?

    > 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 most likely not require participation in a routing protocol,
    > nor have stringent requirements for convergence, dead neighbour
    > detection. we may possibly think of them more as static routes.

Right, I think we should have this... I also think it simplifies how things
like virtual machine systems might work; HNCP gets them a prefix, and they
are always a stub network too.

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Nov 2014 13:29:00 -0800

Michael,

> specific route into the LLN.  Is this what you were trying to say?

homenet advertises a default into LLN.
or LLN discovers a default from homenet.

LLN advertises more specifics into homenet.

> are always a stub network too.

the LLN may not get a prefix from the homenet. that depends. the LLN may make up its own from ULA, or it may get one from LLN cloud provider. the LLN could even number the homenet.

cheers,
Ole

---

From: Steven Barth <[email-masked]>
Date: Mon, 17 Nov 2014 22:44:14 +0100

> the LLN may not get a prefix from the homenet. that depends. the LLN may make up its own from ULA, or it may get one from LLN cloud provider. the LLN could even number the homenet.
To clarify: the "full-featured" HNCP routers would then iterate over 
it's LLN-neighbors HNCP-data, and create appropriate routes with 
next-hop being the LLN for each assigned prefix with an R-Flag (buddy 
router flag if i got the PDF right) and / or some other TBD injection-TLV?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 18 Nov 2014 00:31:40 +0100

> algorithms like prefix delegation to run fully distributed.

I'd like to emphasise this sentence, since that's the bit that had slipped
my mind before Steven pointed it out (by private mail).

-- Juliusz

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Nov 2014 22:57:49 -0500

Juliusz Chroboczek <[email-masked]> 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 explain more.

I don't see the issue if all routing nodes which hear (i.e. are on-link with)
the LLN gateway advertise the link, and advertise the LLN prefix as if it
was learnt through the routing protocol.
Maybe there is something I'm missing here.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Nov 2014 23:05:43 -0500

Not a valid topology.   This is the correct topology:

>   LLNgate (aka Thermostat)
>  L---+---L
>    L-+-L

the low power nodes are not the gateway.  That just doesn't work.

    > A and B agree on the fact that L is unreachable.

There is no impact on the low power nodes or the gateway. This is inevitable.

    > especially if L had more than just two Homenet neighbours.

So you are saying you think that the looping L traffic will consume all of
the bandwidth of the wireless network, and that will keep the routing
protocol from converging again.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Nov 2014 23:11:12 -0500

> then using ICMP might be an easy way to do this.

Yes, ICMP exactly does it.
ICMP ND exactly.  Traffic to the nexthop (likely a LL address) fails to
resolve with ND, and that causes the link to go down, and the route to be
withdrawn.   This is exactly how it always works today.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Nov 2014 23:18:01 -0500

> dongle that has a linux driver to talk to?

The LLNgateway (e.g. Thermostat in the Nest case) has wifi or wired
ethernet as well as the 15.4 radio.   Some of these gateways already run
*WRT, some are powered (sometimes PoE) versions of LLN platforms, and so are
rather small.  While doing the latter is popular among makers of the LLN
platform, because it's something they know, going forward, it won't work,
because you need a less constrained management node.

    > makes eyes at nest folk) (?)

Contiki is very popular.

    > pi, and parallela as high end... Aside: has anyone played with a

:-)

---

From: Teco Boot <[email-masked]>
Date: Tue, 18 Nov 2014 07:46:09 +0100

> Op 17 nov. 2014, om 17:53 heeft Margaret Wasserman <[email-masked]> het volgende geschreven:
> 
> 

The link state protocols may have loops during convergence. Babel has not. I had babel in mind here.

If we include 1. low probability on routing loops and 2. optimized for wireless links, including wireless mesh on the RP requirement list, I am fine.

Teco

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 18 Nov 2014 12:55:13 +0000

On 11/18/14, 1:46 AM, "Teco Boot" <[email-masked]> wrote:

>
>> Op 17 nov. 2014, om 17:53 heeft Margaret Wasserman
>><[email-masked]> het volgende geschreven:
>> 
>> 
>>> 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 this, than any
>>other router?  Are we likely to run into these problems whenever a
>>router that is connected to more than one peer goes away?
>

What feature of babel keeps traffic from looping during re-convergence?

Thanks,
Acee 

>
>If we include 1. low probability on routing loops and 2. optimized for
>wireless links, including wireless mesh on the RP requirement list, I am
>fine.
>
>Teco
>
>
>
>> Margaret
>> 
>> 
>

---

From: Dave Taht <[email-masked]>
Date: Tue, 18 Nov 2014 05:14:43 -0800

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 trouble
thinking that a better-then-rasberry pi class processor could be hooked to
less than 16MB ram effectively and certainly not work well as an AP,
as you do need quite a lot of ram to forward aggregates....

Back in 1998 I had given up on scaling up vxworks to do ipv4, and
worked on scaling linux down to fit into 16MB of ram and a floppy disk
to boot from
in order to make an AP (
http://the-edge.blogspot.com/2010/10/who-invented-embedded-linux-based.html
)

(and thus, an industry was born)

And these days we regularly run APs with 4MB of flash doing ipv4, and
8-16MB of flash
doing ipv6, routing, etc, etc in openwrt, usually with about 32MB of
ram as a base - on
much weaker processors than an A8.

So it is unclear how good the thermostat is as an AP, but if it has a
smaller OS (BSD?), possibly
16MB of ram is enough these days to run as a basic AP + 802.14
gateway, and we have already
shown babel and hnetd as being very, very lightweight.

On Mon, Nov 17, 2014 at 12:23 PM, James Woodyatt <[email-masked]> wrote:
> embedded systems.  It has not much flash and even less memory.  We cut a lot
> of things out to make everything we need to fit, and we feel significant
> volatile and non-volatile memory pressure on this platform.
>
> for Comms Engineering to insert HNCP, when it's finally deployable. Assuming
> HNCP can be made to work. Lot of ifs. However, whatever happens, we
> eventually will need something that does what HNCP does, and I like HNCP
>> with lasers.
>> (https://twitter.com/RalfMuehlen/status/533414954167070720/photo/1
>> ).
>>

-- 
Dave Täht

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 18 Nov 2014 16:12:16 +0100

> 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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 18 Nov 2014 15:33:10 +0000

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

---

From: Dave Taht <[email-masked]>
Date: Tue, 18 Nov 2014 09:38:01 -0800

> 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…

I cannot quite answer that question well, so I will leave that to juliusz.

I do note that the default 4 sec update interval bugs me. Part of that
is due to having to deal with wifi multicast, which can defer
multicast updates for up to 200ms, and std wifi only transmits at
1mbit (unless you choose to transmit at a higher rate, which many
people do, I have seen 9 and 12mbit in the field).

I have longed to take the source specific version to a top of rack
10GigE switching environment, and crank up the update interval by a
factor of, say, 10000,  to see what happens.

-- 
Dave Täht

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 19 Nov 2014 01:03:55 +0100

> 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.  However, that's where the mechanism outlined in slide
17 kicks in -- the starving router will send a request for a sequence
number increase, which follows the potentially looping route.  There are
two cases:

  * if the route was in fact non-looping, the request will reach the
    source, which will increase its sequence number straight away and
    trigger an update;
  * if the route was in fact looping, then the request will loop just
    once before it is discarded by duplicate detection.

The result is that, in the absence of packet loss, you clear the
starvation in time 20ms per hop (the amount of jitter applied to forwarded
requests).  With a five-hop route, that's just one tenth of a second.

With lossy links, you're going to get timeouts, which will indeed slow
down reconvergence.  See however the experimental data in

  http://ro.uow.edu.au/cgi/viewcontent.cgi?article=1747&context=infopapers

where, in a relatively small but lossy mesh network, an older version of
Babel consistently exhibited packet delivery above 99% and convergence
times on the order of three hello intervals (which is the expected time
needed for the wireless link quality estimator to converge).

(And if you think that this looks like EIGRP's active phase -- you're
right, except that it's less brittle in the presence of packet loss, since
there's no requirement for a global synchronisation, and provides weaker
time bounds in the presence of packet loss, since there's no requirement
for a global synchronisation.  Sometimes you're stuck between a rock and
a hard place.)

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 19 Nov 2014 01:12:24 +0100

> 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, 10000, to see what
> happens.

You cannot, Babel won't go below 10ms.  (Hard-wired in the on-wire
encoding, which carries deadlines in units of 10ms.)

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Tue, 18 Nov 2014 16:20:02 -0800

> It's probably the Hello interval that's biting you, not the Update

Sure.

> encoding, which carries deadlines in units of 10ms.)

Easily fixed in a test environment... am I not allowed to dream of the death
of spanning tree?

-- 
Dave Täht