IETF85 mdnsext BoF (Extensions to the Bonjour protocol suite) Tuesday, November 6th, 2012 15:20-16:50, Grand Ballroom C Chairs: Tim Chown, Thomas Narten Minute taker: Matthew Gast ==== The chairs explained the proposed agenda, and cited the Note Well. The agenda was accepted. Goals of the BoF (Chairs) ------------------------- The chairs then ran through the goals of the BoF, which were given in the context of RFC5434. The room was reminded that to form a WG, the BoF must demonstrate: - there is a problem that needs solving, and the IETF is the place to do it; - there is a critical mass of participants willing to work on the problem; - the scope of the problem is well-defined and understood; - there is agreement that the deliverables are the right set; - it is believed that the WG has a reasonable chance of success. It was noted that there has been very little prior discussion on the mail list (mdnsext@ietf.org), and thus as yet there isn't evidence of a critical mass to do the work. The chairs noted that there has been demand from organisations for a multi-subnet service discovery solution, and that the emergence of early solutions from different vendors indicated a need to consider standardisation and interoperability of solutions sooner rather than later. Presentation 1: Bonjour in routed networks (Stuart Cheshire) ------------------------------------------------------------ slides: http://www.ietf.org/proceedings/85/slides/slides-85-mdnsext-1.pdf Aidan Williams: Company has experience in working with dns-sd at scale. We use existing building blocks, agree with the point that the weakness is DNS updates, particularly when you want to minimize administration. Want to see specifications that are not just drafts because products just depend on it. Aaron Smith, Xirrus: Much rather have dev efforts in standards protocol than clever hacks. Need some consideration for optimizing on Wi-Fi. Stuart: 10 years ago, Wi-Fi didn't exist. 1k multicasts per second on Ethernet are fine, but not on Wi-Fi. Curtis Villamizar: Some work should go forward in service discovery, but this may not be the basis of that work. An unsuccessful hack that is link local only is not an acceptable starting point. Henning Schulzrinne: This is 6-7% of Wi-Fi traffic in a large university. There are now many more devices, and many devices where non-traditional naming (location- or function-based) is the case. There may be a need to work with new devices. Mark Townsley: We need to look at this within the confines of a multi-segment network, and those exist even in home networks. Thomas N: Will Homenet have requirements on this? Mark: An architecture document is pulling together multiple requirements. If it weren't for this BoF effort, we would be ready for IETF last call. Stuart: Homenet wants to discover things between links, and it is expected that a home will have 2-3 links. Cross-link discovery is a requirement homenet has, but if another group takes up that challenge, then homenet doesn't need to do it. Jari Arkko: Confused by relationship between here and homenet. This should not cause delay to homenet. The main danger is that homenet is clear on requirements, but this group will be exploring requirements. The exploration should happen once, not multiple times. Bob Hinden: Fully support this work, and the IETF has been not doing this for too long. The best is the enemy of the good. If multi-link discovery can be as good as single-link today, that is good. Andrew Sullivan: Two people said the problem across links is that DNS updates are hard. Why isn't all of this solved by configuration magic that is an application that needs to happen? Stuart: That is a solution proposal, which is out of scope for today. The software exists in MacOS 10.4, but it is not widely used. Andrew: it sounds like what we need is to have a way to make DNS naming easy to use. Thomas N: there are two solutions: (1) existing mechanism must be extended, or (2) the user tools are not adequate (Andrew nods) Anonymous person: People have this problem today, and this problem needs to be fixed. It's not just multiple links, it's also links with loops. Curtis Villamizar: Another requirement for homenet is that naming works across links. Another requirement is that when connecting to my office, I don't need to replicate services from home into the office or from the office into my home. Multicast-based anycast might help here because it can be TTL scoped. Stuart: This is how multicast discovery works. Curtis: There needs to be a globally-scoped namespace, not just a locally-scoped namespace. mDNS is great when there are no routers. Stuart: Naming of this BoF might be misleading. The real goal is to solve the service discovery protocol, not necessarily to extend mDNS. Ray Bellis: homenet expects to get into home from outside, so Curtis's comment was wrong. On scope, the requirements for mDNS and SD within homenet scope are well understood. Interactions with unicast naming system is the problem. Unidentified person: This is really something we need to do. The difference between homenet and larger scale is also security. Home networks are trusting, campuses are not. Stuart: Taking homenet to university doesn't work. If we keep homenet in mind when building for university/enterprise, we should be able to build a solution that can be put into homenet. Thomas: The majority of equipment I use at home is uPNP, DLNA, P2P. This effort should take into account home devices being taken into the enterprise. Presentation 2: Draft requirements (Kerry Lynn) ----------------------------------------------- slides: http://www.ietf.org/proceedings/85/slides/slides-85-mdnsext-2.pptx Unnamed person: In homenet, there is the favor doctrine. Rather than identify changes and attempt to minimize, focus on the minimization. Phase 0 should require no changes to what is deployed. Kerry: What this expresses is that if you have to choose between two alternatives, it is not always obvious. Phillip Hallam-Baker: On the security model, do not have a single shared key. Don't make me reconfigure the device to the network. My thermostat has made me reprogram my WPA key. Once there is a connection between a device and network, there should never be a reconfiguration. Dan? ?: There definitely needs to be collaboration between this effort and homenet. On security, when there is scope beyond local link, it should be a first-order objective to have security. Security is a main circle. Namespace management between global and local namespace is a problem. Kerry: My observation is that we are looking for a list of requirements. Much of the homenet mailing list is arguments for picking a protocol. I am saying that I am ready to work on a DNS-based solution. Michael Richardson, co-chair of roll: We are trying to make multicast work. People generally think multicast is useful, but the only answer everybody agrees on is that we need multicast to make mDNS work. If there is an mDNS proxy algorithm that is small and easy to implement, it would be easier for everything to be a multicast proxy. Matt Sanders: Might be misinterpreting how namespace works with scalability, but we should not do that exclusively. Most of the use cases we can think of depend on location proximity, and that might not be captured in namespace alone. The current problem in large enterprise networks have as much to do with client behavior and lack of agility. Backoff algorithms for requests/responses, CPU utilization Rodney Simpson: Agree with basing on DNS and mDNS because I need something quickly. When I see talk of global namespace and global links, it makes me think of distributed DNS like Pirate Bay. I would hope this is out of scope. Andrew Sullivan: Since this is a BoF and we are trying to figure out if this is a problem that will lead to a result, why are we devoted to DNS-based anything? DNS and mDNS are different rules for how names go in, as well as rules for what names are like. There may be conflicts between those two domains because of the way applications use them. Kerry: We believe in running code. Stuart: Many applications are written to existing APIs. I made a distinction between API to the service and the protocol used to access the names. Is this directed to mDNS specifically? Andrew: The local scope works because mDNS is only local, and has a local namespace. As soon as we might be talking to the global namespace, there is a problem that mDNS uses UTF8 but global DNS does not. Thomas ?: Follow up on Michael's rant. If roll has problems with multicast, they should consult with pim & mld. I would prefer this works without multicast routing. If there is multicast routing, it should be leveraged. Tom Herbst: This is good work that needs to go on. I would be concerned that if we do multicast proxy, we still need to do multicast on LLNs. I would like to see this work without DNS servers. Dave Taylor: This is a good set of requirements, whether it is DNS or not. Two missing things: (1) reliability, and (2) usability - a long list of things that can't be used is not helpful. There is no liveness expectation in DNS Curtis: It is also useful for authorization. If you are not authorized, it should not show up Stuart: Discovering things that are offline is not helpful. Getting the balance right is a trade-off. With current implementation, there is a window where devices whose power has failed will show up. It is non-zero because making it zero would be too costly. Goals discussion ---------------- Goal#1: Document requirements for four scenarios Agreement on Goal #1, with the exception of 1(d) based on the comments of the roll chair earlier. Goal#2: Develop improved, scalable solution Agreement on Goal #2. Goal#3: Develop solution to integrate zeroconf and unicast name services Agreement on Goal #3. About 30-6 based on a show of hands. Ted ?: Unless the namespaces are integrated, this does not make sense. Either global DNS or mDNS needs to change. Andrew Sullivan: This is a "I want a pony" protocol Question on scoping Useful problem, IETF right place? Tim and Thomas don't feel that this is at the point where there is evidence of consensus to form a working group, but heavy discussion on the mail list after today's BoF could help demonstrate that. Kerry: People are trying to solve this with ad-hoc solutions. The question is whether it should be done in IETF. Thomas: It's easy to say there's a problem to solve. Maybe the problem isn't that we need to fix mDNS, maybe we can fix it elsewhere in the stack. Problem statement clear and well-scoped? Curtis: The right thing to do is avoid mDNS as the basis for this solution. Maturity of requirements understanding? Unidentified person: If this becomes a WG, then there will be two WGs solving this problem: this and homenet. Critical mass? Who would be willing to do work? On requirements document? ~20 authors Wide-area service discovery solution? similar number mDNS/global DNS integration? smaller number Document review? ~5 Ralph Droms (AD): Participants must pitch in before Orlando (IETF 86) to have another BoF. The chairs thanked the attendees, and stated that it's now up to the community to demonstrate interest and commitment to work on the problem on the mail list. The Chairs closed the meeting at 16:55.