Subject: [homenet] Routing Protocol in HNCP

From: Margaret Cullen <[email-masked]>
Date: Wed, 22 Jul 2015 13:53:37 +0200

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 version (-07) mentions a routing protocol below.

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.  However, HNCP interacts intimately with "the routing protocol", and it is not possible to implement or run HNCP without implementing and running a routing protocol.  If two routers implement HNCP but are not running _the same_ routing protocol, they will not work together properly.  These things indicate, to me, that the HNCP spec requires a normative reference to a routing protocol (or conceivably to a routing protocol selection mechanism) to ensure that the same routing protocol is being run on all HNCP routers within a single home.

If you contend that it is possible to usefully run HNCP in a network where different HNCP routers are running different routing protocols, please explain to me how that could work.

Margaret

"[Each router implementing HNCP] MUST implement and run a routing protocol.."
"[Each router implementing HNCP] MUST use adequate security mechanisms for the routing protocol on any interface where it also uses the security mechanisms of HNCP"
"Routing based on source and destination address is necessary."
"Such an interface acts as an internal interface with the exception that HNCP or routing protocol traffic MUST NOT be sent on the interface…"
"[The prefix assignment algorithm] MUST create an appropriate route for said prefix, indicating it is directly reachable on the respective link and advertise said route using the chosen routing protocol."
"The router publishing a prefix with internet connectivity MUST announce an IPv4 default route using the routing protocol"
"A Route Information Option [RFC4191] MUST be added for each delegated IPv6 prefix known in the HNCP network.  Additional ones SHOULD be added for each non-default IPv6 route with an external destination prefix advertised by the routing protocol."
"In addition, the router SHOULD announce a Classless Static Route Option [RFC3442] for each non-default IPv4 route advertised in the routing protocol with an external destination."

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Jul 2015 02:43:15 +1200

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.."
> "[Each router implementing HNCP] MUST use adequate security mechanisms for IsBabeliS on any interface where it also uses the security mechanisms of HNCP"
> "IsBabeliS routing based on source and destination address is necessary."
> "Such an interface acts as an internal interface with the exception that HNCP or IsBabeliS traffic MUST NOT be sent on the interface…"
> "[The prefix assignment algorithm] MUST create an appropriate route for said prefix, indicating it is directly reachable on the respective link and advertise said route using IsBabeliS."
> "The router publishing a prefix with internet connectivity MUST announce an IPv4 default route using IsBabeliS"
> "A Route Information Option [RFC4191] MUST be added for each delegated IPv6 prefix known in the HNCP network.  Additional ones SHOULD be added for each non-default IPv6 route with an external destination prefix advertised by IsBabeliS."
> "In addition, the router SHOULD announce a Classless Static Route Option [RFC3442] for each non-default IPv4 route advertised in IsBabeliS with an external destination."

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.

     Brian

---

From: Sander Steffann <[email-masked]>
Date: Wed, 22 Jul 2015 18:06:21 +0200

Hi Brian,

> about the routing protocol, but that a single routing protocol must be used.

And that "single routing protocol" is ... ???

This basically just ignores the problem that a routing protocol must be chosen and might even open the door to vendor A saying "our single routing protocol is X" and vendor B saying "our single routing protocol is Y". This decision has to be made at some point...

Cheers,
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 23 Jul 2015 04:33:57 +1200

Hi Sander,

> And that "single routing protocol" is ... ???

Irrelevant to *this* discussion. If we want to get the HNCP draft out of the door,
we need it to be independent of the choice.

> This basically just ignores the problem 

No it doesn't. It says that it's an orthogonal problem.

> that a routing protocol must be chosen and might even open the door to vendor A saying "our single routing protocol is X" and vendor B saying "our single routing protocol is Y". This decision has to be made at some point...

Yes, but it's a different decision from "Do we have consensus on HNCP?".

    Brian

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 22 Jul 2015 18:51:04 +0200

> 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 fine protocol, and I would really like to see it published.  Of
course, I'd like to see it published with a choice of routing protocol,
but that is not likely to happen soon, for many reasons (one of those
being that we don't know yet if there is consensus in the IS-IS community
around Lamparter's latest draft -- and without that, there's no usable
IS-IS spec).  (One thing you can do to help is to get people like Hopps
and Gredler to review Lamparter's work.)

Let's please not keep HNCP hostage to the routing protocol issue -- let's
get it published soon.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 22 Jul 2015 17:19:10 +0000

Given discussion during the meeting, I agree with the design team recommendation that HNCP should implement the router protocol selection mechanism (that hopefully would select the most ubiquitously supported router protocol). This would allow HNCP to proceed without a mandatory-to-implement routing protocol decision, successfully work with the protocol we do select, and (as Russ described) potentially allow for a different / better protocol to eventually supersede the protocol we choose this year. 

Per Ray's statements, I expect there will be a draft created that clarifies the unclear requirements and provides some assessment of the 2 candidates against these clarified requirements. Hopefully this will be quick. But in any case, it shouldn't delay HNCP.

If clarity still does not disqualify either protocol, I am very, very, very willing to accept the coin toss approach. 
Barbara

> -----Original Message-----
> From: homenet [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: Wednesday, July 22, 2015 12:34 PM
> To: Sander Steffann
> Cc: [email-masked] Group; Margaret Cullen
> Subject: Re: [homenet] Routing Protocol in HNCP
> 
> Hi Sander,
> 
> >> 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.
> >
> Irrelevant to *this* discussion. If we want to get the HNCP draft out of the
> door, we need it to be independent of the choice.
> 
> > that a routing protocol must be chosen and might even open the door to
> vendor A saying "our single routing protocol is X" and vendor B saying "our
> single routing protocol is Y". This decision has to be made at some point...
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: David Lamparter <[email-masked]>
Date: Wed, 22 Jul 2015 19:19:52 +0200

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 that implementing this single HNCP draft is not enough to
get a full homenet router.  But:
  -- there is *no* claim that the HNCP draft *alone* gets you a full
         homenet router! --
There simply needs to be another document that completes the picture.
But there is no point in holding up HNCP for that document.

-David

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 22 Jul 2015 19:27:21 +0200

> On 22.7.2015, at 19.19, David Lamparter <[email-masked]> 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 it causes confusion, rather fix it and drop the RP dependency except for the border discovery result triggering running / not running of 'a suitable routing protocol' somewhere. 

Cheers,

-Markus

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Jul 2015 06:39:17 +0200 (CEST)

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 it causes confusion, rather 
> fix it and drop the RP dependency except for the border discovery result 
> triggering running / not running of 'a suitable routing protocol' 
> somewhere.

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. If 
we leave it out of HCNP, well then that's a requirement on the routing 
protocol itself to implement a mechanism itself to do it without any prior 
knowledge of what the world looks like.

I had a quick scan through the architecture document and it says that the 
routing protocol is self configurable, so I guess this is why we have 
differing views on what things are up to the routing protocol and what is 
up to the rest of the architecture to set up and influence.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 23 Jul 2015 08:16:21 +0200

> On 23.7.2015, at 6.39, Mikael Abrahamsson <[email-masked]> wrote:

If IS-IS is used, yes.

However, HNCP is routing protocol agnostic document by design (if for no other reason, just the fact that e.g. potential homenet IS-IS profile  will be years in coming due to the normative references). Explicit routing protocol mentions there confuse people, so we plan to remove them instead of adding routing protocol dependencies.

> For me, these are configured, indicating to me that HNCP should do it. If we leave it out of HCNP, well then that's a requirement on the routing protocol itself to implement a mechanism itself to do it without any prior knowledge of what the world looks like.

Why should it? 

You can specify it in-band with the IS-IS profile for homenet.

> I had a quick scan through the architecture document and it says that the routing protocol is self configurable, so I guess this is why we have differing views on what things are up to the routing protocol and what is up to the rest of the architecture to set up and influence.

If you want to configure IS-IS metrics using HNCP, I welcome the draft. The transport is easily enough extensible for probing and announcing even quite dynamic metrics; however, I think it is not really the place for it in base spec as non-IS-IS use cases do not require it. Therefore I do not see the point in having it in the core spec.

For the record, we are going to still remove routing protocol references from the HNCP, except for the optional border discovery one, as they were NOT what was intended. Now is the time to pipe up here (or the second WGLC of HNCP) if tighter binding between HNCP and 'a RP' was seen as desirable by someone. I do not find it elegant; 'addressing and routing should stay separate' (-someone). And regardless of what homenet WG comes up with, decoupled protocols enable different use cases elsewhere.

Cheers,

-Markus

---

From: Teco Boot <[email-masked]>
Date: Thu, 23 Jul 2015 08:47:12 +0200

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 stuff. This was demonstrated in the NS3 talk, the simultaneous startup scenario. Can be improved (as Juliusz suggested already at mic).

It is the task of a routing protocol to find out "what the world looks like". Of course with help from lower layers (e.g. auto-cost). Or kind of ETX/ETT plugin.

Teco

> Op 23 jul. 2015, om 06:39 heeft Mikael Abrahamsson <[email-masked]> het volgende geschreven:
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Jul 2015 09:08:49 +0200 (CEST)

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 are of course other ways of solving this.

I still think it's an oversight that the arch document doesn't say 
anything on this point. Traditionally, a routing protocol takes a bit of 
configuration, such as prefixes/addresses and metrics, and off it goes and 
uses this information to figure out routing. In this case we're saying 
HNCP/hnetd sets up prefixes, but it doesn't set up metrics. This 
clarification would be good to have somewhere.

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 23 Jul 2015 09:14:57 +0200

> On 23.7.2015, at 9.08, Mikael Abrahamsson <[email-masked]> wrote:
> 
> 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 are of course other ways of solving this.
> 
> I still think it's an oversight that the arch document doesn't say anything on this point. Traditionally, a routing protocol takes a bit of configuration, such as prefixes/addresses and metrics, and off it goes and uses this information to figure out routing. In this case we're saying HNCP/hnetd sets up prefixes, but it doesn't set up metrics. This clarification would be good to have somewhere.

I would personally prefer the auto-configured metrics be set up with minimal overhead, that is, without extra traffic on the link.

What could be used for it (locally) are e.g. 

- HNCP traffic roundtrips are one option (and do not require TLVs as you state), but the option is not 'great', as roundtrips occur only when state changes

- An-RP handling (c.f. Babel, manet-ish stuff, ..)
 (even in IS-IS, I believe this would be better solution; moar TLVs = better protocol?)

However, whatever measures are taken, ultimately they boil down to per-node implementation choice. If we spread the metrics in HNCP, we actually are essentially defining it as the RP anyway. as all it is missing are the metrics, and I would rather not go there.

Therefore HNCP document is not the place, as it defines the protocol for most part, and some implementation details (but this is too much of an implementation detail to be relevant, I believe, as it is RP-specific).

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 23 Jul 2015 10:41:57 +0200

> 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 simple and very clean: HNCP redistributes assigned
prefixes into the RP, and the RP redistributes the default route into the
RA server.  Redistribution is a well understood, widely implemented
mechanism, one that we all feel comfortable with.

This is the very reason why David could take shncpd and run it with IS-IS.

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, plain Babel uses 16-bit integers, the Babel-Z extension uses
variable-length vectors of 8-bit integers), what mechanism should be used
to communicate the metric between HNCP and the RP (is the kernel priority
field suitable and what systems implement it?) and how often HNCP should
inform the RP of metric fluctuations.

I'm pretty sure we don't want to go there.

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 23 Jul 2015 10:49:46 +0200

> On 23.7.2015, at 10.41, Juliusz Chroboczek <[email-masked]> wrote:

To be more specific, 

[1] HNCP running daemon (e.g. hnetd) _configures interfaces_ which causes local on-link routes to show up in the local RIB, and eventually get grabbed by the RP.

[2] RP redistributes them to other nodes' RIBs.

[3] RA server grabs the route from RIB and everyone wins.

I prefer this sort of loose binding, and bunch of other protocols deal with local RIB too, so I believe HNCP 'fits' the typical model best this way.

+- the SHOULD border discovery setting of allowed routing protocol interfaces; obviously, we could just deal with _firewall_ and not touch RP at all. I believe we should ensure that HNCP spec only states which interfaces should not have router-router configuration _such as routing protocol_, and leave actual HNCP implemenation - RP interaction implementation choice. (Firewall, reconfigure, rewrite config + boot in the head, ..)

Cheers,

-Markus

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 23 Jul 2015 10:55:52 +0200

> On 23.7.2015, at 10.49, Markus Stenberg <[email-masked]> wrote:
> 

Baed on rereading the text, I am not sure if that was actually helpful; in case of e.g. Linux, there isn't really FIB-RIB separation and essentially you have only FIB (what is shown by e.g. 'ip -6 route'). Anyway, s/RIB/FIB/ if the description sounds odd to you.

-Markus

---

From: Henning Rogge <[email-masked]>
Date: Thu, 23 Jul 2015 10:57:09 +0200

> inform the RP of metric fluctuations.

yes, putting the metric values of links into the HNCP database sounds BAD.

Configuring the type of metric of the routing protocol could be a job
for HNCP (similar to delivering a shared key to the routing protocol,
its a configuration issue). Putting metric values in there does not.

Henning Rogge

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 23 Jul 2015 11:00:41 +0200

> [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 the protocol field set to 43,
and the routing protocol only redistributes proto 43, not the kernel-
installed routes.  This makes it possible for HNCP to control exactly
which routes get redistributed into the RP, and hence put all policy in
HNCP.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 23 Jul 2015 11:04:50 +0200

> 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

---

From: james woodyatt <[email-masked]>
Date: Thu, 23 Jul 2015 13:37:21 +0200

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

Yes. Please do that, Markus. I generally like the border router discovery features, because that’s related to provisioning domains, but I really think it’s past time to stop trying to make HNCP say anything about what routing protocol is in operation in the home network interior routing domain. I don’t even want to see anything that tries to elect one.

Kill it with fire.

> We still need to figure out how routing protocol metrics should be done.

No, we don’t. We really don’t. Leave that for the people who are working on specific routing protocols for home networking.

I think we have reached the point now where, if HOMENET tries to say anything more at all about the routing protocol in the home interior domain, then it will backfire with further loss of organizational credibility. Stop. Just stop. We failed to reach consensus on a mandatory routing protocol. The design team bent over backward to avoid appearing like they were actually make a recommendation, so let’s give them their fig leaf. We know that an election system would be worse than none at all. It’s over. Stop.

There is really no choice left. Ship HNCP without any knowledge of the specific routing protocol in use.

> For me, these are configured, indicating to me that HNCP should do it. If we leave it out of HCNP, well then that's a requirement on the routing protocol itself to implement a mechanism itself to d…

We should absolutely leave the configuration of routing protocol specific routing metrics for the specific routing protocol to do itself, given only the prefix distribution results provided by HNCP, which absolutely needs to be agnostic about the routing protocol or it won’t win consensus required to push it over the line for publication.

> If you want to configure IS-IS metrics using HNCP, I welcome the draft. The transport is easily enough extensible for probing and announcing even quite dynamic metrics; however, I think it is not r…

I would not welcome the draft. I would prefer that it not be written at all.

—james