Subject: [homenet] Configuration must not be carried by the routing protocol

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 25 Jun 2013 18:30:45 +0200

Dear editors, dear group,

After the recent thread on this list, and a number of private mail
exchanges, I'm under the impression that there might be a consensus
that configuration information should not be carried over the routing
protocol.  In this mail, I argue that

  configuration information should be carried by a protocol separate
  from the routing protocol.

We should therefore make serious efforts to ensure that nothing in the
arch documents prevents carrying configuration information in
a separate protocol.  Ideally, we should include language in the arch
document that encourages such a separate implementation, but I'm not
sure if we can build consensus at this point.

This mail is structured as follows:

1. advantages of carrying configuration information over the routing protocol;
2. advantages of carrying configuration information over a separate protocol;
3. possible configuration protocols;
4. conclusions.

1. Advantages of carrying configuration information over the routing
   protocol

I've heard the following advantages claimed for conflating the two functions:

(i)  it is not necessary to implement a new flooding protocol, which
     saves space on resource-limited routers;
(ii) all routers participate in the routing protocol, while a new
     configuration protocol requires ensuring that all routers forward
     the configuration information.

As I've shown with AHCP[1,2], however, a reasonably efficient, purely
user-space, increasing diameter flooding protocol can be implemented
in a hundred lines of C code or so, and takes just a few kB of flash
and a few bytes of memory; this is why I find point (i) above
unconvincing.  Additionally, since homenet is planning to mandate the
implementation of a new routing protocol on all home routers, mandating
a configuration forwarding daemon does not break compatibility any further.

2. Advantages of separating configuration from routing

There are significant advantages to distributing configuration
information over a separate protocol.

(i)   distributing configuration information on a simple dedicated
      protocol makes monitoring and trouble-shooting easier;
(ii)  the architecture is more robust -- issues with the routing protocol
      do not prevent configuration information from being distributed;
(iii) should new requirements arise, it is possible to reuse most of the
      homenet architecture with a new routing protocol;
(iv)  should new requireent arise, it is possible to reuse most of the
      homenet architecture while running multiple routing protocols.

Point (i) is important -- experience with DHCPv4 and RA shows how easy
it is to run into issues with configuration protocols, and how useful
it is to be able to identify and decode configuration packets without
having a full understanding of a complex routing protocol.

Point (ii) is probably of secondary interest, since all implemen-
tations of link-state protocols are perfectly robust and completely
debugged.  However, we all know the pain of recovering a router that
has lost its IP addresses, anything that avoids such pain should be
welcome.

Points (iii) and (iv) are very important to me.  I firmly believe that
once homenet starts being deployed, smart amateurs are going to start
building topologies that we don't even dream of, using link
technologies that we never heard of.  Most probably, the homenet
routing protocol can then be extended to deal with the new topologies;
but before this happens it will be important that people can reuse the
homenet architecture with a different protocol.  Hence, it is vitally
important that the homenet architecture be modular enough to allow
switching routing protocols.

3. Possible configuration protocols

3.1 RA

RAs are ignored by routers, and rightly so -- RAs have no loop
avoidance mechanism, and using RAs to configure routers leads to
a number of problems that I believe to be unsolvable.  Extending the
RA protocol to be suitable for configuring routers is probably not
worth the hassle, and will lead to confusion.

3.2 DHCPv6

There is an IETF standard configuration protocol, and that's DHCPv6.
Other people on this list are more knowledgeable about DHCPv6, so I'll
refrain from making a fool of myself; however, I'll take the risk of
claiming that DHCPv6 (probably with extensions) looks like an
eminently suitable protocol for configuring homenet routers.

3.3 A new protocol

In the Babel experiment, I have designed a new protocol, which
I called AHCP[1,2].  Since AHCP is designed to run before routing is
functional, it makes minimal assumptions about the network -- it only
requires each interface to have a link-local IPv6 address and to be
able to participate in link-local multicast traffic.  An AHCP client
implements an increasing diameter search for an AHCP server.

The full AHCP implementation (client+server+forwarder, with support
for Linux and BSD Unix), consists of 3500 lines of C and 350 lines of
bourne shell code, and compiles to less than 40 kB.  Subset implemen-
tations are possible.  We have found AHCP to be very robust and
reasonably fast even in the presence of massive packet loss.  The
traffic generated is very reasonable, even when simultaneously
rebooting the whole network.

I am not pushing AHCP as the homenet configuration protocol, since
I have good hope that a variant of DHCPv6 can be used.  However, I do
hope that the results of the AHCP experiment can serve as useful input
for this group.

4. Conclusions

For the reasons outlined above, it is my firm opinion that configuration
information should not be carried by the Homenet routing protocol.  Homenet
routers should either be configured by a variant of DHCPv6, or a new
protocol should be designed.

The arch document should be carefully reviewed, and anything that
risks impeding such a solution must be eliminated.  Ideally, the arch
document should encourage separating configuration distribution from
routing.

Should DHCPv6 be finally chosen, I will be glad to collaborate on writing
a tiny DHCPv6 daemon suitable for homenet.  (And I have a fair amount
of experience with writing tiny network daemons to run on 8MB routers.)

[1] http://tools.ietf.org/html/draft-chroboczek-ahcp
[2] http://www.pps.univ-paris-diderot.fr/~jch/software/ahcp/

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jun 2013 14:03:24 -0400

> from the routing protocol.

I do not agree with this statement.

I believe that there are significant number of people who believe that
configuration information *MUST* be disseminated at the same time as routing
information.

I understand that you'd like to see a diversity of routing protocols,
specifically, babel and/or ahcp, and as much as I agree with the sentiment, I
think that we need one good protocol, and that's it.

If you feel that babel/ahcp (I'm not entirely sure if we need both) should be
the homenet protocol over zOSPF:  I'm open to that discussion.

I am relatively ignorant of AHCP at this point, I intend to learn by doing, I
hope by the end of the summer.

    > hope that the results of the AHCP experiment can serve as useful input

I near you, but I believe that we can not achieve out goals if we do not do
configuration at the same time as loop detection and therefore routing.

Specifically, I think that we will have gaping security issues which will be
very hard to close.

--
]               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: Dave Taht <[email-masked]>
Date: Tue, 25 Jun 2013 12:58:49 -0700

> I do not agree with this statement.

I have been on the fence on this issue for a very long time,
preferring to wait for running code, and the opportunity to run it.
Various problems, like the need for a small dhcpv6-pd capable server
have been met, but the prefix distribution issue and choice of a
routing protocol remains a sketchy one.

Do we have consensus that the majority of connections in the homenet
will be wireless?

Does anyone believe that dhcpv6 or the prefix distribution methods
discussed here are sufficient to provision wireless?

> configuration information *MUST* be disseminated at the same time as routing

I agree that there are a significant number of people that think these
two problems are in-inextricably interlinked.

I disagree with that, but would prefer to have thoroughly proven that
they can indeed be nearly/almost/totally separated, which is not the
case. I'm glad some zOSPF code is out there now for quagga and bird,
it's long been on my todo list to experiment with.

> think that we need one good protocol, and that's it.

It would be nice to have one good protocol, for all definitions of "good".

However a profusion of protocols exist, and having in a configuration
protocol the ability to announce and/or select a routing protocol
would be the most flexible.

>     > I have good hope that a variant of DHCPv6 can be used.

Actually I don't share that hope. present-day AHCP isn't sufficient
either, but it did look straightforward to add prefix distribution to
it and iterate forward as to other configuration needs as they were
better defined.

I'd like to see a conversation centered on "what is needed for a
configuration protocol" for a homenet to flush out other requirements
besides prefix distribution. As one example which I pointed out last
week, in order for windows filesharing to work properly, wins server
information needs to be propagated.

>However, I do

Using /128 prefixes makes life tons easier.

> Specifically, I think that we will have gaping security issues which will be

The security problem has not been addressed in zOSPF either.
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
Dave Täht

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

---

From: "ietfdbh" <[email-masked]>
Date: Tue, 25 Jun 2013 16:23:27 -0400

Hi,

Just a comment ...
You say " There is an IETF standard configuration protocol, and that's
DHCPv6."

Actually, the IETF has a number of configuration protocol standards, not
just DHCPv6.
(Standards are wonderful; everybody should have one!)
If you are going to consider using a standard configuration protocol, then
you should also consider, depending on an analysis of the specific needs for
homenet:
 DHCP, Netconf, RADIUS, Diameter, CAPWAP, COPS-PR, and SNMP, amongst others.

 Some of these I would not recommend for homenet, but they are IETF standard
configuration protocols.

David Harrington
[email-masked]
+1-603-828-1401

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Juliusz Chroboczek
Sent: Tuesday, June 25, 2013 12:31 PM
To: [email-masked] Group
Subject: [homenet] Configuration must not be carried by the routing protocol

After the recent thread on this list, and a number of private mail
exchanges, I'm under the impression that there might be a consensus that
configuration information should not be carried over the routing protocol.
In this mail, I argue that

We should therefore make serious efforts to ensure that nothing in the arch
documents prevents carrying configuration information in a separate
protocol.  Ideally, we should include language in the arch document that
encourages such a separate implementation, but I'm not sure if we can build
consensus at this point.

1. advantages of carrying configuration information over the routing
protocol; 2. advantages of carrying configuration information over a
separate protocol; 3. possible configuration protocols; 4. conclusions.

I've heard the following advantages claimed for conflating the two
functions:

As I've shown with AHCP[1,2], however, a reasonably efficient, purely
user-space, increasing diameter flooding protocol can be implemented in a
hundred lines of C code or so, and takes just a few kB of flash and a few
bytes of memory; this is why I find point (i) above unconvincing.
Additionally, since homenet is planning to mandate the implementation of a
new routing protocol on all home routers, mandating a configuration
forwarding daemon does not break compatibility any further.

There are significant advantages to distributing configuration information
over a separate protocol.

Point (i) is important -- experience with DHCPv4 and RA shows how easy it is
to run into issues with configuration protocols, and how useful it is to be
able to identify and decode configuration packets without having a full
understanding of a complex routing protocol.

Point (ii) is probably of secondary interest, since all implemen- tations of
link-state protocols are perfectly robust and completely debugged.  However,
we all know the pain of recovering a router that has lost its IP addresses,
anything that avoids such pain should be welcome.

Points (iii) and (iv) are very important to me.  I firmly believe that once
homenet starts being deployed, smart amateurs are going to start building
topologies that we don't even dream of, using link technologies that we
never heard of.  Most probably, the homenet routing protocol can then be
extended to deal with the new topologies; but before this happens it will be
important that people can reuse the homenet architecture with a different
protocol.  Hence, it is vitally important that the homenet architecture be
modular enough to allow switching routing protocols.

3.1 RA

RAs are ignored by routers, and rightly so -- RAs have no loop avoidance
mechanism, and using RAs to configure routers leads to a number of problems
that I believe to be unsolvable.  Extending the RA protocol to be suitable
for configuring routers is probably not worth the hassle, and will lead to
confusion.

3.2 DHCPv6

There is an IETF standard configuration protocol, and that's DHCPv6.
Other people on this list are more knowledgeable about DHCPv6, so I'll
refrain from making a fool of myself; however, I'll take the risk of
claiming that DHCPv6 (probably with extensions) looks like an eminently
suitable protocol for configuring homenet routers.

3.3 A new protocol

In the Babel experiment, I have designed a new protocol, which I called
AHCP[1,2].  Since AHCP is designed to run before routing is functional, it
makes minimal assumptions about the network -- it only requires each
interface to have a link-local IPv6 address and to be able to participate in
link-local multicast traffic.  An AHCP client implements an increasing
diameter search for an AHCP server.

The full AHCP implementation (client+server+forwarder, with support for
Linux and BSD Unix), consists of 3500 lines of C and 350 lines of bourne
shell code, and compiles to less than 40 kB.  Subset implemen- tations are
possible.  We have found AHCP to be very robust and reasonably fast even in
the presence of massive packet loss.  The traffic generated is very
reasonable, even when simultaneously rebooting the whole network.

I am not pushing AHCP as the homenet configuration protocol, since I have
good hope that a variant of DHCPv6 can be used.  However, I do hope that the
results of the AHCP experiment can serve as useful input for this group.

4. Conclusions

The arch document should be carefully reviewed, and anything that risks
impeding such a solution must be eliminated.  Ideally, the arch document
should encourage separating configuration distribution from routing.

Should DHCPv6 be finally chosen, I will be glad to collaborate on writing a
tiny DHCPv6 daemon suitable for homenet.  (And I have a fair amount of
experience with writing tiny network daemons to run on 8MB routers.)

---

From: Acee Lindem <[email-masked]>
Date: Tue, 25 Jun 2013 20:34:49 +0000

In any case, I just scanned the architecture document and there doesn't appear to be anything that implies a routing protocol will be used to disseminate configuration. Hence, this discuss can be independent of the WGLC. 
Acee

---

From: "Leddy, John" <[email-masked]>
Date: Tue, 25 Jun 2013 20:42:20 +0000

>Do we have consensus that the majority of connections in the homenet

If you really mean wireless not wifi, I would agree.

But don't forget about Zigbee on the wireless side (and futures).

Also technologies using existing wiring; MoCA, HPNA and HomePlug (and
futures).  
They may be for direct attachment (ex. IP STBs) or dongles for ethernet,
wireless, HomeNet router extension.

John

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jun 2013 16:55:49 -0400

> Do we have consensus that the majority of connections in the homenet

Now that the gamers know about bufferbloat, they are realizing why none of
them use wireless for gaming.  my understanding is that 802.11ac will be even
worse for latency.

Gamers matter, because they replace their stuff sooner than anyone else.
It seems that many of telco/ipTV people have figured out that wireless
doesn't work for them.

So, tell me what a "connection" is... one assumes you don't mean TCP
connection...

    > two problems are in-inextricably interlinked.

Good, we agree that there are people who disagree with the original statement.

    > would be the most flexible.

I don't want this.
Then we get into MUST implement routing protocols, and SHOULD implement
routing protocols, etc...

    > information needs to be propagated.

I agree.

    > The security problem has not been addressed in zOSPF either.

I didn't claim that it was.

I am claiming that the decision, "can we trust this configuration
information" may be linked to "what route this this configuration information
arrive".

So, let me rephrase my claim.
I think if we have two protocols, and that they are implemented by seperate
daemons on a router, that they security linkages of state will not be
implemented.  Further, after we document the linkages that we need, we will
effectively have one protocol that runs on two ports using messages in two
different formats.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 25 Jun 2013 22:58:33 +0200

> In any case, I just scanned the architecture document and there
> doesn't appear to be anything that implies a routing protocol will
> be used to disseminate configuration.

Thanks for taking the time to do that.

-- Juliusz

---

From: Tim Chown <[email-masked]>
Date: Tue, 25 Jun 2013 22:11:54 +0100

> In any case, I just scanned the architecture document and there doesn't appear to be anything that implies a routing protocol will be used to disseminate configuration. Hence, this discuss can be i…

Indeed.

Tim

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 26 Jun 2013 00:02:36 +0200

> be used to disseminate configuration.

Yes, it looks you're right.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 26 Jun 2013 00:03:12 +0200

> Actually, the IETF has a number of configuration protocol standards, not

Point duly taken.

-- Juliusz

---

From: Teco Boot <[email-masked]>
Date: Wed, 26 Jun 2013 07:49:23 +0200

> effectively have one protocol that runs on two ports using messages in two

Address configuration and routing are separate daemons for decades. And there is more to do.

Teco

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 26 Jun 2013 15:43:53 +0900

>       protocol makes monitoring and trouble-shooting easier;

Actually, it doesn't, because in the "advantages of a routing protocol"
section above you forgot to mention one important advantage: fate sharing.

If you have one protocol that is distributing all the information in the
network, then all the information is either disseminated to a particular
device or it isn't, and when it is disseminated, it is disseminated all
together.

If you have two protocols, then the two sets of information are
disseminated asynchronously, and potentially - if there is a problem with
one of the two - not at all.

As running IPv4 and IPv6 in parallel shows, it's way harder to make two
things work than just one, because it's so much harder to figure out if
things are working or not.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 26 Jun 2013 10:08:31 +0200

>> Actually, the IETF has a number of configuration protocol standards, not

Not to mention "HC" stands for "Host Configuration" not "Router Configuration." 

RFC 2131 is very clear, 
"   DHCP is not intended for use in configuring routers."
That explicit statement went away in RFC 3315, though the terminology section makes it very clear that a Host is not a Router.
- Mark

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 26 Jun 2013 10:16:44 +0200 (CEST)

On Wed, 26 Jun 2013, Lorenzo Colitti wrote:

> disseminated asynchronously, and potentially - if there is a problem 
> with one of the two - not at all.
>

I agree with this.

As an exmaple there has been great pain with LDP and IGPs in the MPLS 
space, up to the point where people had to invent mechanisms to hack 
around stuff so IGP wouldn't start using the link until the other one was 
done.

<http://tools.ietf.org/html/rfc5443>

So if multiple protocols are to be used, great thought has to be put in to 
make sure the devices know about these mechanisms and can handle 
situations where one of them doesn't work.

I'm sure there are multiple other examples.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Jun 2013 01:50:35 -0700

> That explicit statement went away in RFC 3315, though the terminology section makes it very clear that a Host is not a Router.

The implication being that dhcp prefix delegation is bogus?

Mike

---

From: Teco Boot <[email-masked]>
Date: Wed, 26 Jun 2013 12:19:43 +0200

> That explicit statement went away in RFC 3315, though the terminology section makes it very clear that a Host is not a Router.

I guess you don't intend to turn off Internet access for many because DHCP is not for routers.

Teco

PS: Mail delivered via IPv4, via interfaces on multiple routers with DHCP client enabled.

---

From: Teco Boot <[email-masked]>
Date: Wed, 26 Jun 2013 12:34:51 +0200

> worth the hassle, and will lead to confusion.

RA's are used for address auto configuration, also for routers.
Using RA's has an important advantage: new options can be added easily. This sets up a signaling channel to all nodes. Non-upgraded hosts shall ignore the new options. Upgraded hosts (like MPTCP) need such info. I'm not a great fan on implementing a large set of flavors of routing protocols on hosts. Hosts are not homenet-only, that is why I highly prefer a single solution that works on many types of networks.

RA packet is single hop. Info in RA comes from other places, could be manually configured, could be from remote. There are many proposals adding some kind of hop-by-hop RA option. Loop-free dissemination is not an issue.

So I have to disagree here, RA is a viable option.

Teco

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Jun 2013 09:52:32 -0400

> That explicit statement went away in RFC 3315, though the terminology section makes it very clear that a Host is not a Router.

DHCPv6 PD is explicitly for configuring routers, so I think this assertion is wrong.   I think Lorenzo's argument is a better one.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 26 Jun 2013 16:42:46 +0200

> DHCPv6 PD is explicitly for configuring routers, so I think this assertion is wrong.   I think Lorenzo's argument is a better one.

The routing protocol should be able to draw most (maybe all?) settings
from watching the interface addresses of the local router and maybe a
special local routing table. This should allow to minimize
synchronization problems.

Henning Rogge

--
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: Mark Townsley <[email-masked]>
Date: Wed, 26 Jun 2013 19:42:09 +0200

On Jun 26, 2013, at 3:52 PM, Ted Lemon wrote:

> DHCPv6 PD is explicitly for configuring routers, so I think this assertion is wrong.   

This was linked back to the assertion that "the IETF has a configuration protocol, it is DHCP" or some such. I was simply trying to point out what "the IETF" has on record in this regard.

Certainly, we often use protocols beyond their original intent. RFC 5218 calls this "Wild Success", with plenty of examples. 

DHCPv6 PD has been referred to by one of its co-authors as "a Fax replacement", so that the user doesn't have to type in his prefix sent to him in printed form from his ISP. I think that analogy was given to sway anyone away from trying to rely on it for more than a very long-lived, essentially static, value from an ISP. 

> I think Lorenzo's argument is a better one.

Agreed.

- Mark

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Jun 2013 10:46:53 -0700

> DHCPv6 PD has been referred to by one of its co-authors as "a Fax replacement", so that the user doesn't have to type in his prefix sent to him in printed form from his ISP. I think that analogy wa…

Isn't a Somebody's-Law that states that "every successful protocol will become a
transport protocol for something else"?

Mike

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Jun 2013 14:05:40 -0400

> DHCPv6 PD has been referred to by one of its co-authors as "a Fax replacement", so that the user doesn't have to type in his prefix sent to him in printed form from his ISP. I think that analogy wa…

I find this sort of report remarkably unhelpful in making design decisions.   Like all IETF consensus documents, the DHCPv6-PD document is a product of the working group and, ultimately, the IETF.   An opinion expressed by one author at one time during the development of the document provides us with little guidance as to how to interpret the document in the present.   What's in the document should stand on its own.   Certainly current use cases treat DHCPv6-PD as dynamic, not static, for varying values of dynamic right up to "forced renumbering every day."

I also find statements like "the IETF has a configuration protocol, it is DHCP" to be unhelpful, because it's even less grounded in any consensus process.   But let's not fight fire with fire—I think most people reading this statement would have the same reaction to it that we do.   Certainly, a working group chair who used a statement like this as part of a consensus determination would be making a grievous error!

---

From: David R Oran <[email-masked]>
Date: Wed, 26 Jun 2013 14:22:52 -0400

On Jun 26, 2013, at 1:46 PM, Michael Thomas <[email-masked]> wrote:

> transport protocol for something else”?Yup. I claim
> 
Yup - I claim to have coined that one.
DaveO.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Jun 2013 11:24:36 -0700

> Yup - I claim to have coined that one.

Heh -- I definitely heard it from you first :)

Mike

---

From: Ole Troan <[email-masked]>
Date: Wed, 26 Jun 2013 15:13:39 -0400

what do we need for distributing configuration information between routers?
a distributed database.

what's a routing protocol?
a distributed database.

do we need to invent a separate distributed database for each class of information?

cheers,
Ole

---

From: Jim Gettys <[email-masked]>
Date: Wed, 26 Jun 2013 15:15:24 -0400

On Wed, Jun 26, 2013 at 2:24 PM, Michael Thomas <[email-masked]> wrote:

>>>>>> That explicit statement went away in RFC 3315, though the terminology
>>>>>> section makes it very clear that a Host is not a Router.
>>>>>>
>>>> This was linked back to the assertion that "the IETF has a
>>>> configuration protocol, it is DHCP" or some such. I was simply trying to
>>>> point out what "the IETF" has on record in this regard.
>>>>
>>>> Certainly, we often use protocols beyond their original intent. RFC
>>>> 5218 calls this "Wild Success", with plenty of examples.
>>>>
>>>> DHCPv6 PD has been referred to by one of its co-authors as "a Fax
>>>> replacement", so that the user doesn't have to type in his prefix sent to
>>>> him in printed form from his ISP. I think that analogy was given to sway
>>>> anyone away from trying to rely on it for more than a very long-lived,
>>>> essentially static, value from an ISP.
>>>>
And it's soooo true, though I managed to discourage using X protocol as an
RPC framework, back in the day.

Unfortunately, no success with HTTP :-(.
                               - Jim

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 27 Jun 2013 00:15:39 +0200

> in the "advantages of a routing protocol" section above you forgot
> to mention one important advantage: fate sharing.

Agreed.  That is a thought-provoking argument indeed.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 27 Jun 2013 00:37:21 +0200

> routing protocols, etc...

We define The One Homenet routing protocol.  Full stop.

We don't want any options in Homenet (RFC 1869, page 2), we want
a clean protocol stack that guarantees interoperability.  However,
this should not prevent us from designing it as a modular collection
of protocols (using already-deployed protocols whenever possible)
rather than throwing everything including the kitchen sink into one
monstruous protocol that nobody is ever able to reimplement from scratch.

> information" may be linked to "what route this this configuration
> information arrive".

I don't buy this.  Actually, I don't buy any claims about security
that don't include a clearly defined threat model and don't show how
the proposed policy applies to the threat model.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 27 Jun 2013 00:56:03 +0200

> what's a routing protocol?

No, it isn't.

A link state protocol implements a replicated -- not distributed --
database within each area.  (All of the local link-state databases
must be exactly identical, or else all hell breaks loose.)

In a distance vector protocol, the set of RIBs of all the routers is
nothing like a database -- every router has a different vision of the
network, since each router has potentially selected different routes.
The only thing that's roughly synchronised is the set of reachable
prefixes, and even that is not fully replicated in the presence of
filtering or aggregation.

> do we need to invent a separate distributed database for each class

Yes, because different kinds of information have different
requirements.  There is information that needs to be reliably
synchronised in a timely manner (the link-state DB), there is
information that must be distributed in a timely manner but need not
be synchronised throughout the network (configuration information),
there is global information that is too large to be distributed except
on demand (DNS), there is local information that is not distributed
except on demand (mDNS), and probably many other kinds that I'm missing.

-- Juliusz

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Jun 2013 16:10:53 -0700

> except on demand (mDNS), and probably many other kinds that I'm missing.

I'm not sure that I have an opinion on this debate, but I'd like to
point out that there are probably other classes of information that
have little to do with routing, but a lot of desire to be replicated
across a homenet's routers. For example if I have a DNS repository,
I'd sure like to be able to take a dead router, throw it in the trash,
plug in a new one, all the while where my network still was serving
up my names.

DNS in particular has ways to transfer the zones, but I'm less certain
about whether there's anything that would orchestrate that hot standby
kind of desire, and I'm even more dubious that it would satisfy zero/littleconf
requirements even if there were.

Picking ULA's seems to be another kind of problem that needs some
kind of config replication/coordination too at the router level if it's
to be zeroconf.

Whether routing protocols would be a good fit, I don't know but it seems
like an odd way to think about the problem to me.

Mike

---

From: Henning Rogge <[email-masked]>
Date: Thu, 27 Jun 2013 07:55:30 +0200

On Thu, Jun 27, 2013 at 12:56 AM, Juliusz Chroboczek
<[email-masked]> wrote:
> ....

I agree with Juliusz, putting all information transfer in the homenet
(including routing decisions, configuration and DNS?) area into a
single protocol is crazy. We don't gain a lot by this strategy except
a lot of complexity and inflexibility in the implementation.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Thu, 27 Jun 2013 08:28:35 +0200

> a lot of complexity and inflexibility in the implementation.

There are different aspects such as single routing protocol, single routing protocol instance, single daemon.
Reusing existing stuff, clean separation of functionality and good efficiency are all nice goals. We end up somewhere in the middle and improve from there.

Just the routing protocol choice: do we need a single protocol for IPv4 and IPv6? With single instance and single topology? Is multicast routing fully integrated? A lot of questions already.

Teco