date:20141117


Andrew Sullivan  wrote:
> Under DNSSEC, either the CPE has to be in the NS RRset (because
> otherwise it would fail validation; but this exposes an NS on the CPE
> to the world), or else it's not.  I guess the idea is to answer
> authoritatively without being in the NS RRset?  Some resilience
> mechanisms will treat that as a ijacking attempt, but I suppose if
> validation passes they shouldn't.

The CPE is also often the recursive resolvers for the home, so I don't see
the issue.

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



pgpSVwM6pRde5.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Stub-only Babel [was: Next Steps for Routing Protocol]


Dave Taht  wrote:
> 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?

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.

> 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) (?)

Contiki is very popular.

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

:-)

-- 
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





pgpMu7xCAL9dW.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol


Henning Rogge  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 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.

> If Homenet assume any "lightweight nodes" (e.g. a Nest node) speak IP,
> 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.


-- 
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





pgpDDxCudMYwk.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol


Juliusz Chroboczek  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 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

Not a valid topology.   This is the correct topology:

>   A-B
>\   /
> \ /
>   LLNgate (aka Thermostat)
>  |
>  L---+---L
>L-+-L

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

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

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

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

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.

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



pgpbxWFFLt8FH.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

Juliusz Chroboczek  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.  

-- 
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-

pgpwNndWCRwNb.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

> Well HNCP itself maintains a link-state database in order to allow
> 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol






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.

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?


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

2014-11-17 Thread Ole Troan

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 trying to say?

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

LLN advertises more specifics into homenet.

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

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

Re: [homenet] Next Steps for Routing Protocol


Ole Troan  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.

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





pgpM4LbGEsRv4.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

2014-11-17 Thread Ole Troan

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for HNCP

Pierre Pfister  wrote:
>> 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.

> 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).

Huh?  Nobody is suggesting HNCP or RP (other than RPL) for the LLN.
It's about the gateway (which in James' case, is the Nest Thermostat
platform) to the LLN which is also on the home wifi (does it have a cable
too?).  I don't know the Nest at all, I assume that it has a power source,
my digital (non-smart) one gets 12V from the furnace.

The gateway has to run LLN-happy protocol (RPL or another), as well as
something to advertise the LLN's stub network (probably a different ULA than
the homenet; no renumbering allowed) into the homenet.

James has come with the belief that his gateway would be unable to run RP.
I think is fear is unfounded.

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

pgpA4BKvGyYi7.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

2014-11-17 Thread James Woodyatt

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  wrote:

> On Sat, Nov 15, 2014 at 7:55 AM, Juliusz Chroboczek
>  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
> 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.
>
> >> 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 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.
>
> >
> > 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
> >
> > ___
> > homenet mailing list
> > homenet@ietf.org
> > https://www.ietf.org/mailman/listinfo/homenet
>
>
>
> --
> Dave Täht
>
> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
james woodyatt 
Nest Labs, Communications Engineering
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] Babel for TinyOS [was: Stub-only implementation of Babel]

> http://www.tinyos.net/

  http://blog.antoine.li/files/2011/09/babel_paper.pdf

I don't think they ever finished their implementation.  (But at least
I got to visit Lucerne.)

-- Juliusz

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Stub-only implementation of Babel

On Mon, Nov 17, 2014 at 10:12 AM, Steven Barth  wrote:
>
> On 17.11.2014 19:09, Dave Taht wrote:
>>
>> Statically linked on x86_64 it is 853k. :)
>
> 40KB with musl (CC="musl-gcc -static -Os -s").

I am not, repeat, not going to pull down the devkit for

http://www.tinyos.net/

And looking at RPL...

as I can easily see losing a week or more to playing with it. :)

-- 
Dave Täht

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Stub-only implementation of Babel



On 17.11.2014 19:09, Dave Taht wrote:

Statically linked on x86_64 it is 853k. :)

40KB with musl (CC="musl-gcc -static -Os -s").

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Stub-only implementation of Babel

Statically linked on x86_64 it is 853k. :)

I am now intensely curious if I could get it to compile on a 16 bit
arch with a less bloated libc.

On Mon, Nov 17, 2014 at 9:45 AM, Michael Richardson
 wrote:
>
> Juliusz Chroboczek  wrote:
> > It's some 900 lines of code (not counting boilerplate), of which 400
> > are support functions (wrappers around sockets functions, mostly).  It
> > compiles to 12 kB of code on AMD64.  It's possible to make it smaller,
> > but at the cost of clarity.
>
> I just wanted to re-interate: 12K. I assume that is with a shared libc, so
> you aren't counting that as part of the 12k.
>
> Thank you for doing this.
>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>



-- 
Dave Täht

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

On Mon, Nov 17, 2014 at 9:20 AM, Henning Rogge  wrote:
> On Mon, Nov 17, 2014 at 5:38 PM, Juliusz Chroboczek
>  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 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).
>
> yes.

yes.

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

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?

>
> Henning Rogge
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Dave Täht

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Stub-only implementation of Babel


Juliusz Chroboczek  wrote:
> It's some 900 lines of code (not counting boilerplate), of which 400
> are support functions (wrappers around sockets functions, mostly).  It
> compiles to 12 kB of code on AMD64.  It's possible to make it smaller,
> but at the cost of clarity.

I just wanted to re-interate: 12K. I assume that is with a shared libc, so
you aren't counting that as part of the 12k.

Thank you for doing this.

-- 
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





pgpuAsHYQuiBz.pgp
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

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.

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 ] 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 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.
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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

2014-11-17 Thread Henning Rogge

On Mon, Nov 17, 2014 at 5:38 PM, Juliusz Chroboczek
 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 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).

yes.

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

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

2014-11-17 Thread Margaret Wasserman


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

On Nov 17, 2014, at 7:02 AM, Margaret Wasserman  wrote:

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

2014-11-17 Thread Margaret Wasserman

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  wrote:

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

2014-11-17 Thread Margaret Wasserman

On Nov 16, 2014, at 8:44 PM, Teco Boot  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 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

2014-11-17 Thread Henning Rogge

On Mon, Nov 17, 2014 at 5:08 PM, Juliusz Chroboczek
 wrote:
>> 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 been a cure for this...
>
> 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.

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

> 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 been a cure for this...

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

2014-11-17 Thread Mikael Abrahamsson


On Mon, 17 Nov 2014, Juliusz Chroboczek wrote:

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.


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.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

On Mon, Nov 17, 2014 at 7:06 AM, Juliusz Chroboczek
 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 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

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

-- 
Dave Täht

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol

> 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for HNCP

2014-11-17 Thread Pierre Pfister

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


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

Re: [homenet] Next Steps for Routing Protocol

2014-11-17 Thread Markus Stenberg

On 17.11.2014, at 10.32, Steven Barth  wrote:
> 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 proposal is sufficient for the intended 
>> purpose.
> 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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Next Steps for Routing Protocol