Subject: [homenet] draft-chroboczek-homenet-configuration-separate-00

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 03 Jul 2013 03:41:47 +0200

Dear chairs, dear group,

I have just submitted

  http://www.ietf.org/id/draft-chroboczek-homenet-configuration-separate-00.txt

in which I argue that configuration information should be carried by
a protocol separate from the routing protocol.  I hope that this can
be used as a basis for discussion.

Dear chairs, please let me know whether you want me to prepare a short
talk on the subject for the Berlin meeting, or whether you think it is
premature.

Thanks for listening,

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Jul 2013 22:14:05 -0400

> be used as a basis for discussion.

Normally we just discuss the arguments for and against on the mailing list, rather than publishing drafts. The points you make in favor of your position are vacuous—essentially, they are just your opinions, stated in an organized manner.   As a working group participant, not an AD, I don't think this draft contributes anything to the discussion.

Honestly, I hate this sort of opinion-based debate; I don't mean to single you out, because you're not the only person with a horse in this race, but what I care about is a solution that works and requires minimal changes on the host.   Babel has some clear shortcomings in that regard.

I would be much more interested in a comparison between proposed solutions that shows what they do well and what they do poorly, rather than someone's opinions organized into a draft.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Jul 2013 22:39:37 -0400

> Normally we just discuss the arguments for and against on the mailing list, rather than publishing drafts. The points you make in favor of your position are vacuous—essentially, they are just your…

Sorry, I realized when I read this back that it was really harsh.   I think the work you guys have done on Babel is good work—the point of saying this is not to say that Babel is a bad idea, or shouldn't be considered.   It's that the way we should consider it is by comparing it point by point against the alternatives on a technical basis.

The considerations you've raised here are not inconsequential—they're just not what I would consider to be first-order considerations.   They are more considerations that we might use in choosing between two solutions that were otherwise equally good.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 02 Jul 2013 22:46:07 -0400

Actually, it seems to me that if we even want to be able to consider 
other routing protocols, our job will be much easier, and the 
architecture much cleaner, if we do not couple the configuration 
distribution problem to the routing protocol problem.

If we are sure we will pick the right answer to the routing problem, 
then sure, use that for all our needs.

I know how much confidence I have in my ability to make this call.

Yours,
Joel

On 7/2/2013 10:39 PM, Ted Lemon wrote:
>> Normally we just discuss the arguments for and against on the
>> mailing list, rather than publishing drafts. The points you make in
>> favor of your position are vacuous—essentially, they are just your
>> opinions, stated in an organized manner.   As a working group
>> participant, not an AD, I don't think this draft contributes
>> anything to the discussion.
>
> Sorry, I realized when I read this back that it was really harsh.   I
> think the work you guys have done on Babel is good work—the point of
> saying this is not to say that Babel is a bad idea, or shouldn't be
> considered.   It's that the way we should consider it is by comparing
> it point by point against the alternatives on a technical basis.
>
> The considerations you've raised here are not inconsequential—they're
> just not what I would consider to be first-order considerations.
> They are more considerations that we might use in choosing between
> two solutions that were otherwise equally good.
>
> _______________________________________________ homenet mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/homenet
>

---

From: Dave Taht <[email-masked]>
Date: Tue, 2 Jul 2013 20:13:45 -0700

> The considerations you've raised here are not inconsequential—they're just not what I would consider to be first-order considerations.   They are more considerations that we might use in choosing b…

The argument here is about AHCP, not babel, actually. There have been
misstatements made here of late about configuration information,
notably prefix distribution, requiring a routing protocol for various
"necessary" reasons.

AHCP's methods are a good counter-argument to many of those arguments,
and it's been "running code" for the last several years, and readily
available in many a distribution. So going to the extent of a written
document that attempts to draw a line in the sand as to overall
philosophy regarding configuration and the need for routing seems
useful.

I agree that I'd like to see a good comparison document, but always
tend to prefer more working code....

(Incidentally: after having long misunderstood the AHCP forwarding
mechanism, last night I was able to add ipv6[1] support to over a
dozen machines in a heavily routed network in a manner currently
impossible with dhcp-v6, with nearly zero configuration, which was
pretty cool (basically I just had to apt-get install ahcpd, identify
the interfaces and start the daemon). No need for dhcp-like relays or
other complexities. It may make it more possible to do "directionless"
configuration similarly to hipnet...

Certainly there exists room for multiple routing protocols in the
universe, of note being ospf, isis, bgp, babel, batman, olsr(v2),
oadv, and whatever 6lowpan is up to nowadays.

What I'd like to move the debate to: is "what needs to be configured
in a homenet" rather than the underlying means of distributing it...
because far more than prefix distribution is required. And I'd
certainly like it if it worked well with ipv4 as well. There are hard
questions there, and if you look hard at the history of dhcp you can
see all sorts of legacy stuff in there that was once very important,
and now no longer is... except for the people that need it to work.

I've already pointed out that support for distributing a WINS protocol
server would be needed in a routed home windows based network. There
are dozens of other examples, here:

http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Client_configuration_parameters_in_DHCP

> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

[1] I could have just as easily have had ahcp manage the ipv4
addresses too but the pain of having to renumber anything without an
adequate dns naming scheme deterred me. But that's a job for mdnsext.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Jul 2013 23:22:08 -0400

On Jul 2, 2013, at 10:46 PM, Joel M. Halpern <[email-masked]> wrote:
> Actually, it seems to me that if we even want to be able to consider other routing protocols, our job will be much easier, and the architecture much cleaner, if we do not couple the configuration distribution problem to the routing protocol problem.

Well yes, fine, you believe that, but wouldn't it be better if we made our decision on the basis of a rational comparison between alternatives, rather than on belief?

The reality is that a fully functional homenet is probably going to require keeping at least three different caches coherent: the naming cache, the routing cache and the configuration cache.   If you disagree with this, that's certainly a valid debate to have.

If you don't disagree with this, though, then it's completely rational to suggest using an existing cache coherency protocol that currently distributes routes to distribute names and configuration information as well.   It's not the only solution, and it may not be the best solution, but it's certainly a valid solution.  The basis for rejecting it should be that there's a better solution, not that "it's too complicated."

And BTW, if homenet routers are to interoperate, we really probably do need to choose a routing protocol, and not try to be flexible.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Jul 2013 23:24:31 -0400

> http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Client_configuration_parameters_in_DHCP

I've tried and failed to improve the wikipedia article on DHCP.   You really shouldn't rely on it as a good source of information about DHCP.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 02 Jul 2013 23:44:47 -0400

Actually, for much of the data in those three caches, there is no 
obvious reason to keep them "aligned" or distribute them together.

My starting point is that there has been a lot of work on home-relevant 
configuration and home-relevant routing.  We also know that home 
networking technologies have changed a lot of the years.  And we know 
that there is a significant range in needs.   Thus, I can well believe 
we mandate something now for interoperability.  But we may well want to 
be able to evolve that.  In the absence of a strong argument for 
coupling, both technology and architectural history (divide and conquer) 
would recommend separation.

Yours,
Joel

On 7/2/2013 11:22 PM, Ted Lemon wrote:
>> Actually, it seems to me that if we even want to be able to
>> consider other routing protocols, our job will be much easier, and
>> the architecture much cleaner, if we do not couple the
>> configuration distribution problem to the routing protocol
>> problem.
>
> Well yes, fine, you believe that, but wouldn't it be better if we
> made our decision on the basis of a rational comparison between
> alternatives, rather than on belief?
>
> The reality is that a fully functional homenet is probably going to
> require keeping at least three different caches coherent: the naming
> cache, the routing cache and the configuration cache.   If you
> disagree with this, that's certainly a valid debate to have.
>
> If you don't disagree with this, though, then it's completely
> rational to suggest using an existing cache coherency protocol that
> currently distributes routes to distribute names and configuration
> information as well.   It's not the only solution, and it may not be
> the best solution, but it's certainly a valid solution.  The basis
> for rejecting it should be that there's a better solution, not that
> "it's too complicated."
>
> And BTW, if homenet routers are to interoperate, we really probably
> do need to choose a routing protocol, and not try to be flexible.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Jul 2013 23:56:02 -0400

On Jul 2, 2013, at 11:44 PM, Joel M. Halpern <[email-masked]> wrote:
> In the absence of a strong argument for coupling, both technology and architectural history (divide and conquer) would recommend separation.

To be clear, what we are hearing here is a very weak argument _against_ coupling, which I am rejecting because it is weak.   We haven't heard any argument _for_ coupling.   We have heard some folks talk about a solution that uses a routing protocol to keep the configuration cache coherent as well.

What I am trying to argue against is rejecting a proposal out of hand because it uses the same cache coherency mechanism for all three databases.  We should reject it for some technical reason: that there is an alternative that works better, or that it doesn't work well.

(I should point out that since we need to support lowpan networks as leaf networks, clearly we are not going to be running the same routing protocol throughout the network.  But lowpan networks should never be transit networks; I think we do need a common routing protocol for transit networks, or we are going to wind up with an ever-expanding interoperability maze.)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 03 Jul 2013 13:52:59 +0200

> mailing list, rather than publishing drafts.

I'm a little confused.  From what Mark explained to me (by private
mail), I was under the impression that publishing a draft is the right
way to prompt discussion of a subject at the next meeting.  I'm sorry
if I misunderstood, and would be grateful if you told me what is the
right way, perhaps after discussion with Mark.

> The points you make in favor of your position are vacuous

Oh?

> Babel has some clear shortcomings in that regard.

I'm even more confused.  There is absolutely nothing in this draft
about Babel.

> you're not the only person with a horse in this race

Ted, I've said it before, but it bears repeating.  I am not pushing
Babel as the Homenet routing protocol.  I am not pushing AHCP as the
Homenet configuration protocol.

I will be very happy if RIPng, OSPF, IS-IS or another respectable
layer 3 routing protocol is chosen as the Homenet routing protocol.
(And yes, I'm dead serious about RIPng.)

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Jul 2013 08:59:10 -0400

> right way, perhaps after discussion with Mark.

I think what Mark is hoping you will publish is a draft describing something positive you have to contribute to the discussion.   What I would like to see is a presentation of what you think the solution of the problem ought to be, not what you think it ought not to be.   It's clear that you have something in mind.   Putting it down in a draft would be very constructive.

To be clear, the working group hasn't been considering solutions in a serious way yet, because we were waiting on the architecture document, which I think is now close to done.   But we've already had presentations on solutions, and I _think_, perhaps incorrectly, that you are reacting to them.  Perhaps you felt that you couldn't present a solution yet, but if so I would encourage you to reconsider.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 3 Jul 2013 13:19:19 +0000

> To be clear, the working group hasn't been considering solutions in a serious way yet, because we were waiting on the architecture document, which I think is now close to done.   But we've already…

<chair hat="on">

+1 - what Ted said

<chair>

Ray

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 03 Jul 2013 15:22:17 +0200

> What I would like to see is a presentation of what you think the
> solution of the problem ought to be, not what you think it ought not
> to be.

Ah, I read you now.

> It's clear that you have something in mind.  Putting it down in
> a draft would be very constructive.

I do have some ideas, granted, but I am pretty sure they will evolve
significantly after I have a chance for an extended chat with Markus
and others.

> To be clear, the working group hasn't been considering solutions in
> a serious way yet [...]  Perhaps you felt that you couldn't present
> a solution yet, but if so I would encourage you to reconsider.

May I assume that you and other interested parties have read
draft-chroboczek-ahcp-00?

What I fear is that if I present AHCP, people will think that I'm
pushing AHCP in its current form rather than as a basis for future
work, and positions will cristallise prematurely.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Jul 2013 09:43:36 -0400

> draft-chroboczek-ahcp-00?

I found the description of the architecture frustratingly brief, and I have not read the document in detail because of that.

> work, and positions will cristallise prematurely.

I think that's a reasonable fear, but you don't have to present AHCP—you can just present an architecture.      The difference between this and the current architecture document would be that yours would be really specific.   This sort of thing is a really useful exercise, because when you try to clearly express what it is that you think should be done, you are forced to think through the details, and suddenly things that weren't fleshed out in previous versions of the protocol become clear.

---

From: Jim Gettys <[email-masked]>
Date: Wed, 3 Jul 2013 10:41:59 -0400

On Wed, Jul 3, 2013 at 9:43 AM, Ted Lemon <[email-masked]> wrote:

> I found the description of the architecture frustratingly brief, and I
> have not read the document in detail because of that.
>
> I think that's a reasonable fear, but you don't have to present AHCP—you
> can just present an architecture.      The difference between this and the
> current architecture document would be that yours would be really specific.
>   This sort of thing is a really useful exercise, because when you try to
> clearly express what it is that you think should be done, you are forced to
> think through the details, and suddenly things that weren't fleshed out in
> previous versions of the protocol become clear.
>
> I've never seen an IETF working group shy about "improving" a protocol
being worked on in that group; rather the reverse, particularly if
shortcomings of an existing protocol are pointed out.

Generally, it's designs done *without* existence proofs that go wrong, go
wrong, go wrong...
                                 - Jim

---

From: Jim Gettys <[email-masked]>
Date: Wed, 3 Jul 2013 10:45:52 -0400

On Tue, Jul 2, 2013 at 10:46 PM, Joel M. Halpern <[email-masked]>wrote:

> Actually, it seems to me that if we even want to be able to consider other
> routing protocols, our job will be much easier, and the architecture much
> cleaner, if we do not couple the configuration distribution problem to the
> routing protocol problem.
>
> If we are sure we will pick the right answer to the routing problem, then
> sure, use that for all our needs.
>

I will note that I raised my concerns about coupling configuration to
routing (since I foresee routing needing to evolve) last year (or was it
the year before?), and it fell on deaf ears.

This concern about coupling configuration and routing is an *architectural*
issue, and the time to capture architectural concerns is *now* as work on
that is finishing up.  As to what routing or configuration protocol, I have
no horse in either race.
                                          - Jim

>> ______________________________**_________________ homenet mailing list
>> [email-masked] https://www.ietf.org/mailman/**listinfo/homenet<https://www.ietf.org/mailman/listinfo/homenet>
>>
>>  ______________________________**_________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/homenet<https://www.ietf.org/mailman/listinfo/homenet>
>

---

From: mike <[email-masked]>
Date: Wed, 03 Jul 2013 07:59:21 -0700

On 7/3/13 7:45 AM, Jim Gettys wrote:
>
>
>
> On Tue, Jul 2, 2013 at 10:46 PM, Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Actually, it seems to me that if we even want to be able to consider other routing protocols, our job will be much easier, and the architecture
>     much cleaner, if we do not couple the configuration distribution problem to the routing protocol problem.
>
>     If we are sure we will pick the right answer to the routing problem, then sure, use that for all our needs.
>
> I will note that I raised my concerns about coupling configuration to routing (since I foresee routing needing to evolve) last year (or was it the 
> year before?), and it fell on deaf ears.
>
> This concern about coupling configuration and routing is an *architectural* issue, and the time to capture architectural concerns is *now* as work 
> on that is finishing up.  As to what routing or configuration protocol, I have no horse in either race.
>                                 - Jim
>
>
There may be a couple of things being conflated. In general, code reuse is a Good Thing,
and the allure of doing so for something complicated like a replicated database is quite
reasonable. However, reusing the basic mechanisms for distribution, damping, healing,
etc, etc is not necessarily the same as using the same mechanisms in *parallel* with, say,
the routing payloads. That is, we can snarf up, say, ospf, change what are in the payloads
to something other than routing information, and run it on another port. Ports are cheap,
after all. Maybe it requires a fork, maybe it doesn't; individual code base's decision.

NB: I'm not advocating any particular solution; only trying to clarify our options.

Mike, who's contemplated reusing NNTP for flood filling things other than alt.binary.*

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Jul 2013 11:17:41 -0400

> Mike, who's contemplated reusing NNTP for flood filling things other than alt.binary.*

Hm.   Basing homenet routing/configuration distribution on NNTP.   Finally some revolutionary thinking.

;)

---

From: mike <[email-masked]>
Date: Wed, 03 Jul 2013 08:28:13 -0700

> Hm.   Basing homenet routing/configuration distribution on NNTP.   Finally some revolutionary thinking.
Hacking on gnus in 3...2...1... :)

Mike

---

From: mike <[email-masked]>
Date: Wed, 03 Jul 2013 08:34:10 -0700

> draft-chroboczek-ahcp-00?

I had not, but now I've skimmed it over. Since I just skimmed, the question
that didn't get answered in the introduction is how this differs from DHCP
with a relay? It might be worth adding that in the tl;dr top sections.

Mike

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 4 Jul 2013 01:22:02 +0900

> the year before?), and it fell on deaf ears.

One of the problems here is: what exactly is "configuration"? For example,
does "configuration" extend to "which prefix is assigned to a specific
interface"? IMO that's clearly a piece of information that *should* be
coupled with routing, because one doesn't work without the other.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 03 Jul 2013 15:04:16 -0400

If folks would like to consider using RFC 2334, that would seem a 
reasonable way to achieve decoupling in my book.

Yours,
Joel

On 7/3/2013 10:59 AM, mike wrote:
>> consider other routing protocols, our job will be much easier, and the
>> architecture
>>     If we are sure we will pick the right answer to the routing
>> problem, then sure, use that for all our needs.
>>
>> routing (since I foresee routing needing to evolve) last year (or was
>> it the year before?), and it fell on deaf ears.
>>
>> This concern about coupling configuration and routing is an
>> *architectural* issue, and the time to capture architectural concerns
>> is *now* as work on that is finishing up.  As to what routing or
>> configuration protocol, I have no horse in either race.
>>                                 - Jim
>>
>>

---

From: Ray Hunter <[email-masked]>
Date: Wed, 03 Jul 2013 21:48:47 +0200

Lorenzo Colitti wrote:
> On Wed, Jul 3, 2013 at 11:45 PM, Jim Gettys <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I will note that I raised my concerns about coupling configuration
>     to routing (since I foresee routing needing to evolve) last year
>     (or was it the year before?), and it fell on deaf ears.
>
>
> One of the problems here is: what exactly is "configuration"? For
> example, does "configuration" extend to "which prefix is assigned to a
> specific interface"? IMO that's clearly a piece of information that
> *should* be coupled with routing, because one doesn't work without the
> other.

Good question. I think we need some more basic architecture rules of how
this is all going to plug together.

Here's a straw man that I'm sure can be improved with some debate..

"Homenet Configuration Information" is the set of parameters, settings,
and other data required by a set of devices to participate in a Homenet
and transmit traffic from end user applications in a nominal manner,
excluding any data directly tied to the end user application or session,
but explicitly including routing information and well as prefix assignments.

Homenet Configuration Information can be further classified on three
orthogonal axes.

1) Temporary or Persistent.

Persistent information is likely to survive a reset, power cycle or
reboot of a single device, without having to be relearned from another
device.
Temporary information is not likely to survive a reboot or power outage.

2) Distributed or non-distributed.

Distributed information is required to be known by more than one device
in the Homenet.
Non-distributed is only required to be known on an individual device.

3) Internal or External

Internal information is sourced or generated from within the Homenet.
External information is derived from a source external to the Homenet.

An example of distributed, temporary, internal configuration information
could be the set of active routers in the Homenet.

An example of persistent, distributed, external configuration
information could be a root certificate or other token that uniquely
identifies the Homenet.

Further:

A Homenet consists of 2 classes of device: end nodes and routers.

A router forwards packets between end nodes.

And end node terminates end user application traffic flows.

Derived Architecture Rules:

A device MAY simultaneously act as a router and an end node. e.g. a
router that also acts as a media store.

Homenet SHALL support a Common Homenet Routing Protocol.

All Homenet Border Routers MUST participate in the Common Homenet
Routing Protocol. Other Homenet Routers SHOULD participate in the Common
Homenet Routing Protocol. Other routing protocols MAY be present in
Homenet e.g. for LoWPAN connectivity, but these alternative routing
protocols MUST NOT take precedence over the Common Homenet Routing
Protocol if there are alternative routes learned via two alternative
sources.

An end node MAY participate passively in the Common Homenet Routing
Protocol, where it MAY learn all routes in the Homenet, and inject
routes used to transmit/receive traffic from its own interfaces, but it
MUST NOT forward traffic on behalf of other end nodes (otherwise it
becomes a router).

Distributed configuration information that is temporally dependent
SHOULD be distributed in either a single protocol, or via a set of
tightly-coupled protocols that include synchronisation of configuration
information (fate sharing).

External configuration information SHOULD be injected into the Homenet
at Homenet Border Routers.

External configuration information MAY be learned from a configuration
GUI or from a partner ISP router.

External configuration information SHOULD be derived from existing
mechanisms deployed at the ISP boundary e.g. DHCPv6-PD, ICMP RA.

Configuration information MAY be distributed in one of three information
distribution layers:

Base bootstrap: The minimum set of configuration information required to
learn or identify any devices as sources of further information e.g.
next hop router, DNS server for end nodes, router neighbors.

Homenet Essential: Common information likely to be required by all nodes
that participate in the Common Homenet Routing Protocol e.g. to learn
the set of Homenet border routers.

Homenet Optional: Additional information that is likely only required
for a subset of nodes or applications e.g. discovery of print servers or
media players

Base Bootstrap MUST be supported by all end nodes in the Homenet.

Essential configuration distribution MUST be supported on all routers.

It is desirable, but not essential, to identify a common Homenet
Optional distribution layer.

Does that take us a step forward?

regards,
RayH

---

From: Michael Thomas <[email-masked]>
Date: Wed, 03 Jul 2013 13:07:06 -0700

> Here's a straw man that I'm sure can be improved with some debate..

Question: is that *just* about *routing* configuration, or about a *router*
configuration. The distinction being that modern home routers often do
many more chores, some that have little to do with routing per se. I got
the impression that that was at issue but could be wrong.

Mike

---

From: Ray Hunter <[email-masked]>
Date: Wed, 03 Jul 2013 22:24:11 +0200

> Michael Thomas <mailto:[email-masked]>
> 3 July 2013 22:07
ALL configuration for ALL homenet devices, including end nodes.

Which is why I think we need to look at a layered set of solutions, with
each layer almost certainly consisting of a number of protocols.

There's no point in having a nice standardised routing protocol if the
end nodes still can't resolve names.

On the other hand, trying to shoe horn all of DHCPv6 and all it's future
(vendor) extensions into a routing protocol clearly ain't going to work
either.

Whereas identifying a common (distributed) configuration repository for
optional configuration information, and how to query it based on DHCPv6,
might just work.

> Ray Hunter <mailto:[email-masked]>
> 3 July 2013 21:48
>
> ------------------------------------------------------------------------

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 04 Jul 2013 03:14:37 +0200

> Temporary information is not likely to survive a reboot or power outage.

Is client-side information about DHCP leases temporary or persistent?

(I'm wondering if it wouldn't be useful to consider the classic
difference between "hard" and "soft" state -- hard state being state
that is difficult or impossible to recover if lost, while soft state
is state that can be recovered easily if lost.  Classic NFS, for
example, is "stateless" in the sense that all hard state is persistent.)

> Homenet SHALL support a Common Homenet Routing Protocol.

The CHiRP.

> Homenet e.g. for LoWPAN connectivity,

Ok.

> but these alternative routing protocols MUST NOT take precedence
> over the Common Homenet Routing Protocol if there are alternative
> routes learned via two alternative sources.

Hmm... does that imply that a device that participates in both the
CHiRP and the LoWPAN protocol MUST follow a CHiRP route in order to
reach other devices on the LoWPAN subnet?

> information (fate sharing).

Could you please give some examples of such "temporally dependent"
information?

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Jul 2013 21:23:21 -0400

> Is client-side information about DHCP leases temporary or persistent?

It's RECOMMENDED that it be persistent, but not REQUIRED, since it can be recovered from the server.

---

From: Ray Hunter <[email-masked]>
Date: Thu, 04 Jul 2013 11:28:52 +0200

> Juliusz Chroboczek <mailto:[email-masked]>
> 4 July 2013 03:14
I thought this classification would be useful in Homenet, as there are
likely to be devices that do not contain persistent storage.

These devices should be able to take part in Homenet, but may not be
able to perform all functions.

If you have better ideas, please bring them forward.
> reach other devices on the LoWPAN subnet?
Good point.

Others have stated a belief that LowPAN will never be used as an
interconnect, and will always be a "stub" network.

Generally, we know pretty well how to deal with multiple sources of
routing information, and it generally involves tagging the original
source, and then filtering information at the appropriate boundary or
applying an administrative distance. But if you have multiple connection
points of non-synchronised information, and the boundaries are
automatically discovered, you will always end up with some pathological
cases e.g. "split brain"

How about:
Other routing protocols MAY be present in Homenet e.g. media specific
routing for LoWPAN connectivity, but these alternative routing protocols
MUST NOT take precedence over the Common Homenet Routing Protocol for
path selection to off-media destinations if there are alternative routes
learned via two alternative sources of routing.

> Could you please give some examples of such "temporally dependent"

How about:

"temporally dependent" is defined as related configuration information
that would lead to potential instability, flapping, or loss of end user
sessions, if it is not tightly coordinated during state transitions.
 
I think it's easier to think of the corollary: there is no (strong)
temporal binding between configuring a print server or NTP server on an
end node, and the identification of homenet border routers IMHO.

So IMHO the debate on whether to use AHCP OR routing based prefix
assignment OR SNMP OR whatever as *the* Homenet configuraton protocol is
bogus, because none of them can configure everything we need.

We need to identify the groupings that do make sense and that are
essential for all nodes, for all routers, and the rest of the optional
"stuff", and identify a (set) of protocols for setting these configurations.

Whereas we certainly do NOT want to kitchen sink all configuration items
into the Essential layer, nor bloat the Bootstrap layer so much that
sensors run out of storage, or become too expensive to produce.

I think there IS a tight binding between topology discovery, identifying
homenet border routers, identifying external interfaces to an ISP
network, identifying internal interfaces, injecting external source
routes into the routing process, enabling a routing process and
discovering neighbors and advertising routes on internal interfaces,
enabling BCP ingress and egress filtering and firewall functions on ISP
interfaces, and *potentially* with prefix assignment. You probably also
want all of the above to be well coupled with the state of DHCPv6 PD or
other upstream link to the ISP router.

Does that make sense to you?

regards,
RayH

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Jul 2013 10:02:24 -0400

> likely to be devices that do not contain persistent storage.

Generally speaking, I think devices of this type are probably either end nodes or non-edge participants in a 6lowpan network, so they don't need to maintain state anyway.   If the edge routers can't maintain state, that's a different matter.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Jul 2013 10:18:31 -0400

> Which is why I think we need to look at a layered set of solutions,
    > with each layer almost certainly consisting of a number of protocols.

    > On the other hand, trying to shoe horn all of DHCPv6 and all it's
    > future (vendor) extensions into a routing protocol clearly ain't going
    > to work either.

so we have stateful configuration of IPv6.
Let me recap, stating the obvious, so that I know that I am on the same page
as others.

We have the M and O bits in the RA.
I think that we will typically have M=0 and O=1.
The client then asks for more information via DHCPv6, which goes to a
link-local multicast address. (I'm unclear when the site-scoped address is
used).

I don't think that *anything* can or *should* change here(*)
(What and how the client does DNS vs mDNS vs sdnsext is a higher-level issue
for the moment)

The question is: how does the non-ISP-connected router get the right
information to use to answer the DHCPv6 requests it sees and/or realize that
it shouldn't run full DHCPv6, but rather just be a DHCPv6 relay.

So I think that the set of information that the *routers* need to exchange is
really not that large, if we assume that the "DHCPv6 server is HERE" is one
of those pieces of information.

(*)   THERE IS STILL an issue of what do hosts and routers do if there are
      two ISP connected routers, and potentially two completely different
      sources of DHCPv6 information. Even in the simplest two ISP case,
      hosts can see both of these DHCPv6 servers directly.

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

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: mike <[email-masked]>
Date: Thu, 04 Jul 2013 08:42:11 -0700

>        hosts can see both of these DHCPv6 servers directly.

Maybe there's really a few things going on here? There is clearly some ISP specific
information that ought to be relayed to the host. But there's also "configurator
of last resort" insofar as since there generally isn't much clue in the routers, the
ISP's fill the void by providing that information. Sometimes it's benign, sometimes
it's in the ISP's self interest. And if we have two ISP's due to multihoming, there's
going to be conflict if it's of the self-interest kind for the ISP's.

As far as I can tell now, it would just be a race in the multihoming situation, right?
Pretty much whichever DHCP server responded first (or their relay) would win which
could cause some inconsistency for configuration that is "shared". DNS, for example,
might give different results if, say, one of my upstream providers answered queries
differently than another because one has, say, a service to do split horizon DNS to
fake up names for my home and the other doesn't. Or if you hate that example, there
have got to be dozens of others in the kitchen sink of DHCP options.

I'm not exactly sure what ought to be done about that because each ISP is incented
to be the ultimate truth of configuration information. It seems to me that the only
arbitrator for such problems is likely to be a human being at home dealing with this.

Maybe the right thing is to synthesize DHCP responses in homenet routers to be
the things that ISP can/will provide, and the choices the homenet wants to chose
when there's conflict?

Mike

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Jul 2013 11:51:07 -0400

> have got to be dozens of others in the kitchen sink of DHCP options.

Work is being done on this in the MIF working group at the moment; we believe the problem is tractable.   To future-proof against work that has not yet completed there, the right thing for homenet to do is make sure that the information is tagged as to its source, and not just dumped into a pot and mixed together.

It may be that for the moment the engine that actually delivers the information to the end node has to do some mixing, but the point is that it should not be mixed before it gets to the final point of delivery, and ideally not even then.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 04 Jul 2013 18:58:42 +0200

> homenet border routers, identifying external interfaces to an ISP [etc.]

> Does that make sense to you?

I understand what you are saying, but I'd like to see concrete
examples of such coupling.  Routing protocols are designed to react in
a timely manner to addressing and topology changes, so I'd expect
address configuration, CPE discovery and the routing protocol to be
able to run asynchronously.

I am probably missing something obvious, but my gut reaction is that
any such "temporal dependency" indicates a mere limitation of the
implementation of the routing protocol.

-- Juliusz

---

From: Ray Hunter <[email-masked]>
Date: Thu, 04 Jul 2013 19:09:27 +0200

> 4 July 2013 18:58
I think you're missing the requirement for automatic topology discovery.

It wouldn't be smart to run an IGP routing protocol either transmitting
or listening on the ISP interface. You don't want it to peer with your
neighbor's CPE on a shared medium just because it's been rebooted. And
vice versa, when the router is moved and plugged in by the user as an
"internal" router, it should learn to start up a routing process in that
case. Normally that topology information is either pre-defined in the
hardware, or soft configured even before the routing protocol starts up.
If you're going to use OSPF to discover topology (and assign prefixes)
you're going to have to send out some types of LSA before others.

regards,
RayH

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 04 Jul 2013 19:16:52 +0200

> I had not, but now I've skimmed it over. Since I just skimmed, the
> question that didn't get answered in the introduction is how this
> differs from DHCP with a relay?

That's a good point, yes.  It almost tempts me to public -01.

I actually considered using a packet format derived from DHCPv6
initially, then decided it's not worth the bother for this particular
experiment.

The main difference is that AHCP defines a forwarding strategy that
allows efficient and redundant communication with no risk of looping.
Perhaps I'm missing something, but it would appear that no such
strategy is defined for DHCPv6 relays.

I haven't actually tried it out, but I believe that AHCP's forwarding
strategy could almost be used with the DHCPv6 packet format -- the one
thing that appears to be missing (but perhaps I haven't looked hard
enough) is a place to store a nonce that allows efficient duplicate
detection.  I that one could store it within an option, but haven't
looked at it in depth.

Then, the layering is different -- AHCP forwarders just blindly
forward packets, without caring about clients and servers, so AHCP
could be used for a peer-to-peer configuration strategy (zOSPF style)
with not changes to the forwarders -- a somewhat important point if
we're going to put the configuration forwarder into the firmware of
millions of homenet routers.

There are other differences, like the ability to mandate that an
option should be used ("Do not use this configuration unless you're
prepared to act on the following option"), but they are probably of
little interest to homenet.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 04 Jul 2013 19:19:09 +0200

> > I am probably missing something obvious,

> or listening on the ISP interface.

Yes, that's it.  Thanks for the explanation.

-- Juliusz

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jul 2013 09:16:05 -0400

mike <[email-masked]> wrote:
    >> (*) THERE IS STILL an issue of what do hosts and routers do if there
    >> are two ISP connected routers, and potentially two completely
    >> different sources of DHCPv6 information. Even in the simplest two ISP
    >> case, hosts can see both of these DHCPv6 servers directly.
    >>

    > Maybe there's really a few things going on here? There is clearly some
    > ISP specific information that ought to be relayed to the host. But
    > there's also "configurator of last resort" insofar as since there
    > generally isn't much clue in the routers, the ISP's fill the void by
    > providing that information. Sometimes it's benign, sometimes it's in
    > the ISP's self interest. And if we have two ISP's due to multihoming,
    > there's going to be conflict if it's of the self-interest kind for the
    > ISP's.

It's also where a clueful user and/or a very-smart router (Apple ones come to
mind) tell hosts about various services that might be present that the hosts
care about.  NTP servers, WINS servers, ... well the v4 list is:
  http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#options

    > As far as I can tell now, it would just be a race in the multihoming
    > situation, right?  Pretty much whichever DHCP server responded first
    > (or their relay) would win which could cause some inconsistency for

I think so.
This is why I think that the router configuration protocol isn't about
talking to hosts or about replacing DHCP, it's about DHCP servers getting
together to be consistent in what they tell hosts.

    > configuration that is "shared". DNS, for example, might give different
    > results if, say, one of my upstream providers answered queries
    > differently than another because one has, say, a service to do split
    > horizon DNS to fake up names for my home and the other doesn't. Or if
    > you hate that example, there have got to be dozens of others in the
    > kitchen sink of DHCP options.

DNSSEC to the rescue :-)

    > I'm not exactly sure what ought to be done about that because each ISP
    > is incented to be the ultimate truth of configuration information. It
    > seems to me that the only arbitrator for such problems is likely to be
    > a human being at home dealing with this.

Well, I think that an ISP that doesn't give the home user access to the
router doesn't deserve any money, but I understand not everyone cares.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jul 2013 09:18:54 -0400

> Work is being done on this in the MIF working group at the moment; we
    > believe the problem is tractable.  To future-proof against work that
    > has not yet completed there, the right thing for homenet to do is make
    > sure that the information is tagged as to its source, and not just
    > dumped into a pot and mixed together.

To the extent that one sees two DHCP servers because one has two interfaces,
MIF has some solutions.

Simply looking at Figure 2 of arch-08, one sees that each hosts can see two
DHCP servers on the two CERs, and none of the hosts has multiple interfaces.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 05 Jul 2013 15:44:08 +0200

> router doesn't deserve any money, but I understand not everyone cares.

Does that imply that the hostile ISP case is out of scope for homenet?

-- Juliusz (who carefully chose an ISP that provides native IPv6, and
   now has to run proxy-ND over a single /64)

---

From: "Howard, Lee" <[email-masked]>
Date: Fri, 5 Jul 2013 10:19:06 -0400

>Does that imply that the hostile ISP case is out of scope for homenet?

There are levels of access that might be granted; an ISP has an incentive
to provide very little rope to a customer, so they don't have to take
phone calls when the customer shoots itself in the foot.  Thus, the home
user may not be able to override your favorite setting.

As a general rule, users should be able to override any setting they wish,
especially if they provide their own router.  But then you start to step
away from the auto-configured, un-administered network, and you don't need
Homenet anymore.

So yes, without villifying ISPs, once a user takes over administration, we
are out of scope of Homent.

Lee

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Mark Townsley <[email-masked]>
Date: Fri, 5 Jul 2013 18:12:29 +0200

> DHCP servers on the two CERs, and none of the hosts has multiple interfaces.

I believe Markus is on vacation, so with my individual contributor hat squarely in place, my understanding is that for the implementation he has worked on the prefix allocation mechanism run within zOSPF ends up designating a single router interface per link in the homenet. This is for purposes of carving out a single /64 (per delegated prefix associated with an uplink from the homenet) for use on each link, but also for designating which router answers hosts connected to given link.

- Mark

---

From: Ted Lemon <[email-masked]>
Date: Fri, 5 Jul 2013 15:51:18 -0400

> To the extent that one sees two DHCP servers because one has two interfaces,

Right, MIF is working on dealing with the issue of multiple provisioning domains on the same wire as well. Don't mistake the name for the referent.