On Jul 23, 2015, at 06:39, Mikael Abrahamsson wrote:
> On Wed, 22 Jul 2015, Markus Stenberg wrote:
>
>> Agreed. I think we will remove routing protocol references from HNCP just to
>> be clear, as in practise what we really interact with is the local route set
>> and not the routing protocol it
> in case of e.g. Linux, there isn't really FIB-RIB separation
The Linux kernel's routing table is almost exactly a FIB.
The RIB is in userspace -- you can see babeld's RIB by sending SIGUSR1 to
the deamon, with Quagga you can use the various "show" commands.
-- Juliusz
> [1] HNCP running daemon (e.g. hnetd) _configures interfaces_ which
> causes local on-link routes to show up in the local [FIB, not RIB], and
> eventually get grabbed by the RP.
It's an implementation detail -- but that's not exactly what shncpd does.
Shncpd installs a duplicate FIB entry with t
On Thu, Jul 23, 2015 at 10:41 AM, Juliusz Chroboczek
wrote:
> What you are suggesting requires some form of tighter binding between HNCP
> and the RP. This raises a number of difficult questions, such as what is
> the metric space (e.g. RIP uses 4-bit integers, IS-IS uses 8- or 24-bit
> integers,
> On 23.7.2015, at 10.49, Markus Stenberg wrote:
>
>> On 23.7.2015, at 10.41, Juliusz Chroboczek
>> wrote:
>> Right now, the interaction between the routing protocol and the rest of
>> the stack is very simple and very clean: HNCP redistributes assigned
>> prefixes into the RP, and the RP redis
> On 23.7.2015, at 10.41, Juliusz Chroboczek
> wrote:
> Right now, the interaction between the routing protocol and the rest of
> the stack is very simple and very clean: HNCP redistributes assigned
> prefixes into the RP, and the RP redistributes the default route into the
> RA server. Redistri
> We still need to figure out how routing protocol metrics should be done.
>
> For me, these are configured, indicating to me that HNCP should do it.
I'll add my 0.50Kč (roughly $0.02) against doing that.
Right now, the interaction between the routing protocol and the rest of
the stack is very s
> On 23.7.2015, at 9.08, Mikael Abrahamsson wrote:
>
> On Thu, 23 Jul 2015, Markus Stenberg wrote:
>
>> If you want to configure IS-IS metrics using HNCP, I welcome the draft.
>
> I do not really want HNCP to configure it, but hnetd could. I am not sure we
> need to spread information regardin
On Thu, 23 Jul 2015, Markus Stenberg wrote:
If you want to configure IS-IS metrics using HNCP, I welcome the draft.
I do not really want HNCP to configure it, but hnetd could. I am not sure
we need to spread information regarding the metrics around the homenet,
but perhaps we should. There a
Mikael,
I know a bit on metrics and wireless links, and a bit on how HNCP works. I
would never ever distribute link metrics with such a configuration protocol.
The beauty of HNCP is that it is silence when data is stable, at a price that
it is not that good in distributing constantly changing s
> On 23.7.2015, at 6.39, Mikael Abrahamsson wrote:
> On Wed, 22 Jul 2015, Markus Stenberg wrote:
>> Agreed. I think we will remove routing protocol references from HNCP just to
>> be clear, as in practise what we really interact with is the local route set
>> and not the routing protocol itself
On Wed, 22 Jul 2015, Markus Stenberg wrote:
Agreed. I think we will remove routing protocol references from HNCP
just to be clear, as in practise what we really interact with is the
local route set and not the routing protocol itself anyway. I guess it
was easier to write the way it is, but as
> On 22.7.2015, at 19.19, David Lamparter wrote:
>
> Fully agree with Brian, Juliusz and the various others - there needs to
> be a mandatory routing protocol, but there's no need at all for HNCP
> need to reference the actual protocol. The HNCP *protocol* works fine
> whatever routing protocol
Fully agree with Brian, Juliusz and the various others - there needs to
be a mandatory routing protocol, but there's no need at all for HNCP
need to reference the actual protocol. The HNCP *protocol* works fine
whatever routing protocol is chosen. The router as a whole doesn't. It
simply means t
s approach.
Barbara
> -Original Message-
> From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Brian E
> Carpenter
> Sent: Wednesday, July 22, 2015 12:34 PM
> To: Sander Steffann
> Cc: homenet@ietf.org Group; Margaret Cullen
> Subject: Re: [homenet] Routing
> I understand that there is some desire to write "modular" documents, and
> I don't object whatever routing protocol is used being documented in
> a different RFC than the HNCP protocol.
Margaret,
You're entirely right, but I would still argue in favour of going forward
with HNCP.
HNCP is a fin
Hi Sander,
On 23/07/2015 04:06, Sander Steffann wrote:
> Hi Brian,
>
>> If that makes sense (for any value of IsBabeliS) I don't think we have a
>> problem.
>> I would suggesting adding text near the beginning stating that HNCP is
>> agnostic
>> about the routing protocol, but that a single rou
Hi Brian,
> If that makes sense (for any value of IsBabeliS) I don't think we have a
> problem.
> I would suggesting adding text near the beginning stating that HNCP is
> agnostic
> about the routing protocol, but that a single routing protocol must be used.
And that "single routing protocol" i
At the risk of receiving the rotten tomatoes left over from this afternoon,
let me try something here. Suppose there was a routing protocol called,
oh, IsBabeliS. Do the extracts that Margaret cited make sense like this?
> "[Each router implementing HNCP] MUST implement and run IsBabeliS.."
> "[Ea
The HNCP document mentions a routing protocol in many locations, including
placing requirements on the HNCP routing protocol and discussing how
information will be taken from and injected into the routing tables in use by
the routing protocol. I have listed the places where the current versio
20 matches
Mail list logo
