Date: Thu, Jul 29th 2010 Meeting Minutes: MIF Working Group Attendees: MIF WG Chairs, Presenters, AD, Attendees (Jabber + In-room) Note Well Agenda bashing We're close to finishing our three chartered work items. Mainly we did analysis. We're going to talk about solutions (not in our charter now) and see about interest and whether to charter work in this wg or another wg. List of drafts to be considered. Last CAlls Problem stmt -05 submitted & commented Current practices draft - received many comments, now updated and in last call, done most of the work. OK to submit? No issues. Will submit. Current practice analysis draft - Julien, Still expanding list of problems Hardly anyone has read it. Please read it, tell if it's useful and if description of problems is accurate. draft-cao-mif-ongoing-session-00 is missing. Are other problems missing? May include it. Doesn't know what's missing, wants to be sure covered before going on to original purpose. Is this useful? Can't ask since so few have read it. Maybe the WG doesn't think this work is useful and just want to recharter and work on solutions. But we can't work on solutions until we finish the analysis that motivates them. The point is to determine where the gaps are. If any member here are proposing a solution and the analysis doc doesn't list a problem you're solving, then why should your solution be chartered? Rechartering proposals ... Is this "interesting" for the IETF? Does this belong in MIF? Who is willing to work on this problem? draft-savolainen-mif-dns-server-selection-03 Slides Do forward and reverse DNS queries efficiently. Know who to ask there. example: Microsoft name resolution policy table. Dave Thaler: are there actually two separate cases/scenarios here or are we only interested in one? What should be in charter? Is the scenario that we are interested in one where the operator wnats to communicate this stuff to hosts, and/or are we interested in one where host wants to do something more intelligent regardless of whether network operators change anything? Teemo interested in both. Need host only at least. Should it be a separate doc? It started as host only and evolved to include network. Do we want to include v4 or forget it? Stuart Cheshire: is there a reason you list the IPv6 prefix separately instead of including it in a list of suffixes? The prefix is just used to generate a domain name, one of which is ipv6.arpa but it's just another domain. Ted Lemon: how many do you expect to see on this list? A: good question, for corporate it might just be corporate.com but it doesn't sound right to allow just one. But can't have list get arbitrarily long. Erik Nordmark: if represent them as domain names instead of prefixes that would help since multiple prefixes in one domain. Thomas Narten: ????????? missed it. Thomas: size problem -- ??? Jark Arkko: Lots of talk about details is premature. Do people need this feature? He thinks yes. But how does it work as a concept? Interaction with DNS. What if two different places provide info about same name. A: DNSOP says it's okay to work on this, they'll review. Policy conflict resolution is a more general problem than DNS, and it's a local policy issue. Dan Wing: this is going to get huge, e.g. Cisco has many domain names and we also access our suppliers through split DNS. Suggest ask DNS what zones it wants to get queries about (but DNS can't do that now). Ted Lemon ... ??????? missed, something about nxdomain Stuart Cheshire: they all hijack the query and give you nxdomain and you have to sort them out. Mark Andrews: have to differentiate external and internal address versions, need to know what kind of address you want, and sometimes you want both. Someone: why are we having this discussion? This should be about rechartering. Yes, recharter the problem, not the solution. Dave Thaler: proposes this is a way for a network to communicate information to hosts. What about what hosts can do with existing solutions? Ted Lemon: Not so much that you're on a network that doesn't tell you everything you need, but that what you hear is NOT directives you're going to follow. Erik Nordmark: good to write down what reasonable heuristics you can use if you're getting insufficient information. Erik again: draft about multihoming without NAT points at MIF. It's not just about multiple interfaces, it's about multiple routers on the same interface. Do we want to expand this stuff? MRW: it's in the MIF charter as a case, there are several parts of that problem but some of them are exactly the same as if there was one network separating you from those two routers, and some if you are on the same network, but certainly two Admin domains ... lost it. Read the current practices draft. Thomas Narten: be careful about the first step, at least in architectural terms what do we want the host behavior to be, then once we know that we know what information we want the host to get. Margaret: Yes. Ted: if we solve the multiple interface problem it's okay if we don't solve multiple DHCP servers on the same wire MRW: restrict to situation where you have names of multiple DNS servers, some of which may have different answers to questions. Do we need a mechanism to deal with that? Me: separate the questions. Ted Lemon: no it's not ops versus protocol, we have to characterize the problem so we can see which parts are ops and which are protocol development. He wants to know what the problem is. But we have a problem statement already. Jari: we do know what the problem is, we're struggling with what the solutions are. OK, make a generic statement of the problem and include all questions in it. Ted Lemon: the problem statement specifically refers to the private namespace problem. Peter Koch: the distinction between the service and the namespace is crucial. Need to serve multiple namespaces. Have to select the right set of nameservers in the face of multiple namespaces. Teemo: his solution doesn't solve all problems [but this is about the problem]. Jari: likes the namespace version of the problem. We don't have a problem if they all have the same namespace. Remi: point is these servers DNS give different answers. Gaetan: this misses potential protocol extensions. MRW: leaving out solution specifics. Stuart Cheshire: would take "private" out of the description, the point is that different servers give different answers. Andrew Sullivan: wordsmithing around the question isn't so important. People are objecting is because the DNS does that even in its regular operation due to different cache states. Ted Lemon: the only reason he's being sticky about it is that the problem statement is incomplete. Don't presuppose the solution. The question: This is the problem where a host receives multiple sets of DNS server configuration information and has to choose which one to use Overwhelming "yes" - raised hands - this belongs in IETF. Yes belongs in MIF but one dissenter: even if host only has one interface still have problem. MRW: MIF includes the case of one interface and two admin domains. Stuart Cheshire: does this WG have the expertise to work on this problem? Yes. Not saying we would restrict solution to just MIF. More than 10 willing to work on it. David Myles, Broadband Forum Liaison See slides Wojciech Dec (aka Woj), Discussion of DHCPv6 Routing Configuration Multihomed host, DHCP client. Connected to two routers A and B to two separate networks. Desire to use B as default gw. A for "special" services. Need more specific routes. IGPs solve this problem? Not supported on hosts. etc. see slides ICMP does not differentiate, but it's normal for DHCP server to give different answers to different hosts. Teemo asks about scaling problem of having lots of prefixes. Woj: use BGP instead in that case. T: if you VPN to your corporation, how can you use BGP? W: use IGP. Today this comes down to just 4-5 routes. Gaetan: It's important to work on delivering this type of info to the host, concern about size, and the mechanism is what we're looking for. Ralph Droms, no hat: the problem you're addressing is a routing problem, and there are other aspects to residential gateway routing. He ruled out today's IGPs because they don't scale right. Ralph agrees. We have a particular topology in residential GW situation, hundred thousand residential GWs one hop away from a single aggregating router. But just because we rule out today's IGPs doesn't mean we shouldn't explore tweaking today's IGPs to solve the problem with a routing protocol. It's a routing problem in both directions due to delegated prefixes having to get to the SP core network somehow, and not just snooping DHCP traffic as it goes by. Back up a little bit, look at this as a bidirectional routing problem. Try to phrase the chartering question. "This" is the problem where a node has more than one next hop, one or more interfaces, and needs to decide what next next hop to use to forward the packet. Suresh Krishnan: what is lacking? See 4191. Woj: add "per node". Thomas Narten: what's missing is "existing solutions to this problem are viewed by some operators as inadequate". Tony Hain: problem is conflict between multiple administrations. Won't run an IGP across two ISPs. Jari text: next hop selection for situations where existing RA and routing protocol solutions are deemed inadequate. What about multiple source addresses? That's the next presentation. Gaetan: should we specify the scope e.g. host versus router? No. It's a "node". Remy: take out "deemed". No. Does it belong in IETF? Yes. Does it belong in MIF? Most yes, but Jari both yes and no. Yes some willing to work. Jari: has to do with characteristics of solution -- DHCP is good but static, simple, not good for dynamic changes. Should also work on routing-based. swb: that's easy, the charter says figure out which solutions are appropriate and then work with other WGs as appropriate. Suresh: scope the work, don't solve all the problems in the Internet. Woj: yes there are more complex solutions, keep to simple "routing" scenarios. Suresh: things are implicit in the draft and should be explicit. Woj: he was told to simplify the draft. Skip Woj's proposed solution. Encourage the three drafts to work together. MIF API Extension - Yuri Ismailov Want to have a problem statement. Choice of interface, the right DNS server, sending packet out on correct interface. MIF API for interface selection, DNS selection, connection manager. An API describing how apps can exploit additional features of multiple interfaces enabled stack. This API should be an optional extension to the current set of networking API, that provides ability of interface selection, dns selection, etc. Lars Eggert: a few times in presentation you assumed that you would pick one best interface and expose it. Work out the concepts on the mailing list. Ted Lemon: likes it. Yes, it's covered in the problem statement already, and we can use that ... APIs to expose multiple interface functionality, e.g. etc. Gaetan: make the APIs "under a coordinated framework". MRW: working on APIs does not preclude coordination underneath. Dave Thaler: IETF generally doesn't do APIs. Usually Austin Group (POSIX) and W3C. IETF version will be informational, "semantic" API. Example: GSSAPI is appropriate. Doing a "abstract" (semantic) API -- consensus. Split on whether to do a concrete API. Do in WG? Yes. Work on? Six or so.