On 17/08/2015 20:34, Eric Vyncke (evyncke) wrote:
> I think that Brian has summarized this renumbering avoidance as "desirable
> but nothing to be depended on"
Exactly. Apps that can't survive renumbering should be regarded as
broken (they are already broken today when roaming, so this is
nothing
On 17.8.2015, at 14.19, normen.kowalew...@telekom.de wrote:
> Hi,
>
> +1.
>
> a) Any idea how often this data changes and really needs a re-write in “a
> typical home" ;-) ?
Not very often, at least if you don’t bother to prune ‘old’ stuff much (it
depends a bit, but most conservative setup w
considered by the file system software authors.
BR,
Normen
-Ursprüngliche Nachricht-
Von: Markus Stenberg [mailto:markus.stenb...@iki.fi]
Gesendet: Montag, 17. August 2015 10:11
An: Toerless Eckert
Cc: homenet@ietf.org; Juliusz Chroboczek
Betreff: Re: [homenet] HNCP: avoiding renumbering
On
> I don't know why Juliusz called stable storage bad.
Ideology.
Soft state good, hard state bad. A network protocol should be able to
recover all the data it needs just by consulting its neighbours. If it
needs stable storage to function, then it's a failed design.
Yeah, I know, I'm a fanatic.
On Sun, Aug 16, 2015 at 11:57 PM, Toerless Eckert wrote:
> On Mon, Aug 17, 2015 at 09:41:24AM +0300, Markus Stenberg wrote:
>> Just like in some other old workplace, cough, ???if it does not work without
>> IPsec, do not expect it to work with it???.
>
> Should i even try to understand that refer
On 17.8.2015, at 9.57, Toerless Eckert wrote:
> On Mon, Aug 17, 2015 at 09:41:24AM +0300, Markus Stenberg wrote:
>> Just like in some other old workplace, cough, ???if it does not work without
>> IPsec, do not expect it to work with it???.
> Should i even try to understand that reference ? ;-)
Hi,
On Sun, Aug 16, 2015 at 11:57:07PM -0700, Toerless Eckert wrote:
> I don't know why Juliusz called stable storage bad.
I'd assume it has to do with flash write cycles on $30 routers...
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG
I think that Brian has summarized this renumbering avoidance as "desirable
but nothing to be depended on"
-éric
On 17/08/15 08:57, "homenet on behalf of Toerless Eckert (eckert)"
wrote:
>On Mon, Aug 17, 2015 at 09:41:24AM +0300, Markus Stenberg wrote:
>> Just like in some other old workplace,
On Mon, Aug 17, 2015 at 09:41:24AM +0300, Markus Stenberg wrote:
> Just like in some other old workplace, cough, ???if it does not work without
> IPsec, do not expect it to work with it???.
Should i even try to understand that reference ? ;-)
> I do not expect homenet stuff to do much better he
On 17.8.2015, at 9.22, Toerless Eckert wrote:
> On Mon, Aug 17, 2015 at 01:01:04PM +1200, Brian E Carpenter wrote:
>> That may be desirable to limit churn, but must not be depended on. The
>> architecture is explicit on pp 25-26 that renumbering is an expected event:
>> https://tools.ietf.org/html
On Mon, Aug 17, 2015 at 01:01:04PM +1200, Brian E Carpenter wrote:
> That may be desirable to limit churn, but must not be depended on. The
> architecture is explicit on pp 25-26 that renumbering is an expected event:
> https://tools.ietf.org/html/rfc7368#page-25
> The addressing, routing and namin
On 17/08/2015 11:01, Juliusz Chroboczek wrote:
which avoids renumbering.
>
>> Why do we care? Homenets need to be renumbering-proof anyway, because
>> the ISP might change the prefix anytime.
>
> You're right, that deserves clarifying. We're trying really hard to make
> sure that in no circ
On 17/08/2015 11:01, Juliusz Chroboczek wrote:
which avoids renumbering.
>
>> Why do we care? Homenets need to be renumbering-proof anyway, because
>> the ISP might change the prefix anytime.
>
> You're right, that deserves clarifying. We're trying really hard to make
> sure that in no circ
>>> which avoids renumbering.
> Why do we care? Homenets need to be renumbering-proof anyway, because
> the ISP might change the prefix anytime.
You're right, that deserves clarifying. We're trying really hard to make
sure that in no circumstances is running a Homenet router worse than
running a
n 17/08/2015 01:01, Markus Stenberg wrote:
>
>> On 16.8.2015, at 14.40, Juliusz Chroboczek
>> wrote:
>> When an HNCP router is restarted, the prefixes it allocated to a link are
>> "adopted" by neighbouring routers; if the router then restarts, it will
>> agree to the prefixes advertised by its
> On 16.8.2015, at 14.40, Juliusz Chroboczek
> wrote:
> When an HNCP router is restarted, the prefixes it allocated to a link are
> "adopted" by neighbouring routers; if the router then restarts, it will
> agree to the prefixes advertised by its neighbours, which avoids
> renumbering.
>
> Unfor
When an HNCP router is restarted, the prefixes it allocated to a link are
"adopted" by neighbouring routers; if the router then restarts, it will
agree to the prefixes advertised by its neighbours, which avoids
renumbering.
Unfortunately, this only applies to link with multiple HNCP routers: on
a
17 matches
Mail list logo
