On Sun, Feb 2, 2014 at 8:47 AM, Acee Lindem <acee.lin...@ericsson.com> 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? > Acee > > On Feb 2, 2014, at 12:45 AM, Lorenzo Colitti wrote: > > On Sat, Feb 1, 2014 at 6:11 PM, Juliusz Chroboczek > <j...@pps.univ-paris-diderot.fr> 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 > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
