Re: [homenet] Homenet protocol decisions

[Dave Taht <[e-mail]>]

On Sun, Feb 2, 2014 at 10:58 AM, Brian E Carpenter
<[e-mail]> wrote:
> On 03/02/2014 06:15, Dave Taht wrote:
>> On Sun, Feb 2, 2014 at 8:47 AM, Acee Lindem <[e-mail]> wrote:
>>> I agree. Also, since we already have to bootstrap an auto-configuring
>>> routing protocol, why not leverage this work to distribute other
>>> information?
>>
>> Because routing protocol authors are generally hostile to adding
>> what is effectively dhcp-like support to their protocols and daemons?
>
> I think there's a reason for that "hostility", which is that in some
> sense everything other than routing is less fundamental, and we need
> to protect routing from the rest by isolating it. If routing fails,
> nothing else can work, after all. So there's a tendency to keep
> the routing protocols "pure".

I will definately argue that a more extensible protocol than a routing
protocol or dhcp as currently defined is needed for configuration.

given the ubiquity of http servers, additional configuration could be
carried by propagating a configuration server url around (and or leveraging
sddp/upnp/pcp/dns-sd).

> However, the great thing about routing protocols is that they really
> are very close to autonomic, and we need that instead of traditional
> top-down configuration. Despite the protests, I detect hints of
> top-downness in many of the messages on this thread. Apart from
> external routes and available global prefixes, what else *needs*
> to be top-down in a homenet?

1) What time is it?

I would personally like it if ntp over ipv6 was encrypted and
multicast within your own borders. I'd settle for all boxes within a
homenet agreeing on the same set of what local time servers are
definitive.

2) Where are my dns server(s)? What do they serve addresses for? The
dns scoping problem has not been addressed here, and it gets horribly
complex rapidly in the presence of multiple isps, vpns, and other
services like the nest stuff. Your vpn is probably going into split
dns in particular...

3) As a couple straw men...

my opposition to iw10 universally is probably pretty well known. The
relevant rfc and research in favor of it was skewed in favor of stuff
coming from high speed/high bandwidth servers...

http://tools.ietf.org/html/draft-ietf-tcpm-initcwnd-00

...instead of the behavior of apps sending stuff from your local (much
slower) network to the internet.

http://tools.ietf.org/id/draft-gettys-iw10-considered-harmful-00.txt

The observable spike from iw10 is quite large on egress from slower
networks, and especially damaging on single queue aqm systems like
codel and pie.

now it turns out iw10 (initcwnd), mtu, and can be set on a per route
basis (at least in linux), and I would not mind at all if my route to
the each source specific gw to the internet from my slower net
advertised a saner iw, and correct pmtu.

That is pretty top-down, and it would be probably best to carry that
info in the routing protocol. (/me ducks)

4) There is a long list of things supplied currently by dhcp, many of
which are obsolete (impress server anyone?), that would be worth going
through in detail. I imagine that there are multiple rfc's following
this one:

http://tools.ietf.org/search/rfc2132

there are many lessons to be learned from dhcp.

>
>    Brian
>
>>
>>> Acee
>>>
>>> On Feb 2, 2014, at 12:45 AM, Lorenzo Colitti wrote:
>>>
>>> On Sat, Feb 1, 2014 at 6:11 PM, Juliusz Chroboczek
>>> <[e-mail]> wrote:
>>>>> And what happens when the routing protocol finds out that, even though
>>>>> the
>>>>> delegation protocol thinks everything is OK and addresses were delegated
>>>>> just
>>>>> fine, the network is now partitioned? How do you reassign addresses in
>>>>> that
>>>>> case?
>>>> I fail to see how this particular functionality requires merging the
>>>> two protocols.  If a link is partitioned, you need to time-out the
>>>> address assignments made by the now unreachable router.  Whether they
>>>> are timed out by the routing protocol or by a separate configuration
>>>> protocol is pretty much an implementation detail, isn't it?
>>>
>>> The routing protocol knows that the network is partitioned because that's
>>> what it does. How is the configuration distribution protocol going to know
>>> that? Either you couple it to the routing protocol, or you have it poll to
>>> see if things have changed (inefficient and/or slow to notice changes). Why
>>> would you do the latter?
>>
>> Several comments:
>>
>> 1) The synchonicity problem exists for multiple layers of the stack.
>> Take DNS for example, when addresses change, dns needs to change also.
>> It's very hard with any form of centralized server for dns to make
>> that fast or atomic.
>>
>> 2) All the interdependencies on config and routing and dns for a
>> highly dynamic ipv6 world are forcing daemon writers to adopt a
>> software bus structure to broadcast and respond to changes to various
>> subsystems controlled by various daemons.
>>
>> In the linux world at least, system configuration information is
>> propigated between daemons mostly along the dbus, and the openwrt folk
>> have implemented a ubus that is lighter weight, that communicates
>> between dhcpv6, dns, dhcpv4 and other daemons.
>>
>> So what's needed is a clear delination of responsibilties for
>> acquiring and pushing out changes to the underlying network
>> architecture, and it doesn't matter what protocol on the wire those
>> run over.
>>
>> 3) So far in dealing with highly dynamic ipv6, and poor interfaces to
>> DNS in particular in the real world, I despise it and go back to
>> wanting a /48 distributed with my house, or at least, some way to buy
>> one from my ISP.
>>
>> 4) In my case at least the prefix distribution problem aint'  problem
>> 'cause I just ship /128s everywhere I need 'em with AHCP.
>>
>> /me ducks
>>
>> Yes, distributing prefixes is needed.
>>
>> 5) To finally get to your own point, there is no need to poll at the
>> protocol level, the daemons on the responsible routers need be aware
>> of changes and push them. Ideally there is some level of
>> authentication involved,
>> particularly in changes pushed like "forcibly retract this ipv6 prefix
>> and use this one instead because my provider just changed me for no
>> f-ing good reason")
>>
>> We've demonstrated that a protocol like AHCP can do that, (and nobody
>> is suggesting that AHCP as currently defined is sufficient, it merely
>> serves as a convenient counter-example to the
>> embed-everything-in-the-routing protocol thread, that anybody can
>> install and run, as it's been available in linux for 6+ years....)
>>
>> 6) A well defined set of TLVs and actions for border discovery, nat
>> detection in ipv4, and carrying dns, ntp, and other core services is
>> needed no matter how they are distributed.
>>
>> 7) I generally despair of this entire debate, and wish more people
>> were writing code, doing experiments, and working inside the real
>> world. I hate that this discussion has ratholed on the method of
>> distribution, rather on than on "what configuration information needs
>> to be propagated inside the home on zigbee, wifi, lte, moca, homeplug,
>> in order to have grandma be able to get her pr0n and meds from her
>> high-tech wheelchair. "
>>
>> me, for example, am observing how src/dst routing works in the real
>> world, and am trying to improve it, deal with bcp38 and vpn
>> technolgies, etc. There is a lot of work to be done to defeat in
>> detail all the existing problems, and I argue strongly for trying
>> stuff, iterating, and trying more stuff, until a viable
>> standard for these problem emerges...
>>
>> ... and that, is probably the basic beef I have in modifying an
>> existing routing protocol. Solving configuration distribution and
>> border discovery, and nat detection, and core service distribution -
>> needs a design small, flexible, and rapidly iterate-able, and
>> *separate*, for these problems.
>>
>> I certainly wish we could foresee all problems in advance; we
>> obviously can't (two years on this thread running), something flexible
>> and iterate-able is needed.
>>
>>> _______________________________________________
>>> homenet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/homenet
>>>
>>
>>
>>



-- 
Dave Täht

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