> Op 16 nov. 2014, om 05:43 heeft Michael Richardson
> het volgende geschreven:
>
>
> Mark Townsley 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 suppo
Pierre,
>> 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.
>
>
>
>
> 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 t
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" wrote:
>Hello Juliusz,
>
>Please have a look at proposal #1 in the pdf Mark joined to this thread’s
>first mail.
I think this conversation has got off on the wrong foot - the start of
it was about routing protocol choice, and the other was how to
interoperate with a stubby nest network in hncp.
On Sat, Nov 15, 2014 at 8:43 PM, Michael Richardson
wrote:
>
> Mark Townsley wrote:
> > routing protocol. A
Juliusz Chroboczek wrote:
>> This included technical discussion around a partially unanticipated
>> requirement for HNCP to support a stub network with a gateway that
>> doesn't have sufficient resources to run a routing protocol.
> Mark,
> Could you please spell out the req
Mark Townsley 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 i
Mark Townsley 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 th
>> While we didn¹t spend a lot of time on it in Thursday¹s meeting, it was
>> proposed that the IoT device domain would never be used for transit so it
>> only needed to get a default (or other aggregate) and inject a prefix and
>> the HNCP could be made to satisfy this requirement.
>
> Could you
Does anyone know anything about homekit is supposed to interoperate?
https://developer.apple.com/homekit/
--
Dave Täht
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
I assume that the trust verdicts would be distributed by hncp, but the
documenet doesn't seem to say so.
Yes, they are. The idea was too limit them in some way since neutral
verdicts can be created by (unusuccessful) external connection attempts
and thus it must be avoided that established nod
section 6.3.3 contemplates sending out verdicts for a period of time
until a decision can be rendered, giving up after 10 minutes.
I think, that since hncp is using trickle, it can just rely on trickle saying
that we haven't got any new information, so just don't say anything.
I assume that the
> While we didn¹t spend a lot of time on it in Thursday¹s meeting, it was
> proposed that the IoT device domain would never be used for transit so it
> only needed to get a default (or other aggregate) and inject a prefix and
> the HNCP could be made to satisfy this requirement.
Could you please c
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 tha
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)"
:
>While we didn¹t spend a lot of time on it in Thursday¹s meeting, it was
>proposed that the IoT device doma
While we didn¹t spend a lot of time on it in Thursday¹s meeting, it was
proposed that the IoT device domain would never be used for transit so it
only needed to get a default (or other aggregate) and inject a prefix and
the HNCP could be made to satisfy this requirement.
On 11/15/14, 10:36 AM, "Ju
> Since the assumption is that the device runs HNCP anyway, the intent is to
> use that for the stub-only routing.
I'm probably just being slow, but I have trouble understanding how that's
supposed to work.
At some point, the stub network needs to be redistributed into the routing
protocol. Who
On 11/15/14, 7:57 AM, "Margaret Wasserman" wrote:
>
>On Nov 15, 2014, at 7:40 AM, Juliusz Chroboczek
> wrote:
>> Mark, please scratch my previous offer to implement a stub-only variant
>>of
>> Babel. Please let me know how much flash and RAM you give me, and I'll
>> do my best to fit Babel into
> In the impromptu meeting on Thursday, I believe that James Woodyatt said
> that his nodes have 64K of ram and that code executes-in-place out of
> ROM. He didn't say how much of that 64K is currently used for data for
> other parts of the system.
A box with that little RAM should definitely be
On Nov 15, 2014, at 7:40 AM, Juliusz Chroboczek
wrote:
> Mark, please scratch my previous offer to implement a stub-only variant of
> Babel. Please let me know how much flash and RAM you give me, and I'll
> do my best to fit Babel into that amount.
In the impromptu meeting on Thursday, I belie
>>> 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
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 informa
> 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 expec
On 14.11.2014, at 21.35, Mark Townsley 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 requ
24 matches
Mail list logo
