Hi As promised, here is my concerns over the proposed discovery service, a long with concers over our current topology model / way of thinking about topology. Discovery service: - Essentially a mechanism to publish (and subscribe to) documents, with the documents emitted through a flooding mechanism. - Documents are signed by their creater. - It is not explained why it is better to have a flooding mechanism to distribute documents instead of distributing only the link to discovery services and subscribing directly from the source. This is despite the latter being significantly simpler, while providing the exact same functionality and with the same amount of messages send in the system. - The flooding mechanism distributes the exact number of messages / documents by pushing them around. It is not more efficient, it just adds more with lifetime, expiration, etc. - The only way to got more effient distribution is to aggregate information somehow, but that is - AFAICT - not done. - Also, I have no idea what it is this thing is trying to do/solve. Signing and distributing the documents like this, still doesn't solve the issue of transitive trust. Say a setup like this: A - B - C A trusts B. B trusts C. A does NOT trust C. A getting information from C, signed by C, does actually do anything, because cannot verify it. What is weird is that if A requests a connection service from A to C, through B, it HAS to trust B, and implicately C, to provide the service. This issue comes up practially everywhere when building networks. You have to trust your provider to deliver your data, and trust your peers to not only announce the right reachability information, but also to deliver data to end users. I'll just repeat it... Signing documents doesn't solve the issue of transitive trust. To transit into the second major issue: Distributing information like this combined with NML means one can acquire network topology descriptions. However in our current system (and way of thinking) we only export one topology per network. The discovery service system further enhances this view of the world by distributing the single description further. However network don't really work like that. They have different policies towards different other networks. I'll use the nordunet network to show how these policies work. You can see an overview of it here: http://stats.nordu.net/stat-q/load-map/ndn-map,,traffic,peak We do several things with our network: - Provide generic connectivity to our few owners/customers (the NRENs of the five nordic countries) - Peer with a number of networks, mainly at NETNOD, AMSIX, LINX, DECIX, along with several Equinix sites and CPS in the US. - We also provide US transit to PIONIER and SURFnet (which we have private links to) - We also have links to GEANT, these are used for transit towards europeans NRENs - We also have services towards RBnet and RUNNET, but I am actually not sure what we provide to them. As you can imagine this is a bit of mish-mash with a lot of policies for who can use the network in what manner. Here are some things we DO NOT allow: - SURFnet & PIONIER to send data to GEANT through us - Allow transit between GEANT and our peerings Both of these lists can be made very long. Most of this is handled with BGP communities (I assume). Essentially NORDUnet is a transit network (I guess all network are that in some sense), but how you can use our infrastructure depends on the agreement you have with us. I can fairly easily create a single topology of our network, but that topology doesn't tell anyone how they can use it. For instance our links over the Atlantic are rather heavily loaded, but additional capacity over the Atlantic costs a significant amount of money (the ANA-100 circuit is attempt of trying to reduce costs over the Atlantic for NRENs), so we are in general not going to allow connections over those link except for special arrangements. Our initial NSI peering are likely to be DeIC, GEANT, SURFnet, and possibly SUNET (Onsala). What I'd like to announce wrt. reachability is something like this: DeIC: SURFnet, GEANT, SUNET SUNET: SURFNET, GEANT, DeIC SURFnet: DeiC, SUNET GEANT: DeIC, SUNET Furthermore we have a potential user through DeIC that may want to reach SLAC which means transatlantic link, so we might announce a different reachability towards DeIC. Our agreement with SURFnet and GEANT might also differ in how other networks can reach us through them, and what they can announce other networks. But this is not really possible currently. I can start to serve different topologies depending on request IP, but that is a hack. So essentially, the problem boils down to this: In our current model, describing topology doesn't tell me how I can use it. This makes path finding rather difficult. The reasons for different policies to different networks is usally political and economical. Right now we have a model that deals mainly with technological aspects of networking, but we cannot ignore the other aspects of it. Furthermore, with networks the size/layout of NORDUnet (and GEANT, ESNet, and more) it becomes rather difficult to perform effecient path finding when having opaque networks. I've been toying with idea of being able to split network into sub-parts (nordunet would probably be nordic, eu, and us), somewhat inspired by some ideas from Jerry, but I haven't gotten around to do something concrete, and I am not entirely sure how useful it is. Anyway, this is just the tip of the iceberg. In short: The discovery service doesn't solve any problem AFAICT. In fact, it just reinforces some dogmas which I think are wrong. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet