MIF Minutes: Tommy Pauly, Ian Farrer Jabber: Mikael Abrahamsson 1 Agenda bashing (Chairs, 3 min) 2 MIF document status review (Chairs, 5 min) 2.1) MIF MPVD API requirements IPR disclosure draft-kline-mif-mpvd-api-reqs 3 MIF working group document update 3.1) draft-ietf-mif-mpvd-ndp-support (Jouni, 10 min) 4 MIF Recharter discussion (Chairs, 45 min) 5 MIF related document 5.1) Homenet naming architecture document (Ted, 10min) 5.2) draft-mccann-dmm-prefixcost (John, 10min) 2 MIF document status review (Chairs, 5 min) Sent Happy Eyeballs draft to IESG Waiting for clarification on MPVD ID on how ID will be used Jouni Korhonen K(JK) - is mif-mpvd-id waiting for clarification from the authors or the WG? MC - After the last meeting, it's from the WG MIF MPVD API requirements IPR disclosure Microsoft has released IPR disclosure under RAND for the MPVD API draft from Erik Kline. This is not a working group draft, but we want the working group to be aware. (There seem to be many IPR disclosures for the working group!) We will have a recharter discussion, but not make a final decision until a broader group on the list and in future meetings. The group here today is relatively small, so we want more input. The AD needs to make all chartering decisions, Options: - Recharter - Go on hiatus until we have more experience with PvDs - Close the group Mikael Abrahammson (MA) - What does hiatus mean in IETF terms? MC - it means that it stays open, the m/l is still there, but it doesn't meet and you set a date for it to see how things are progressing, to either close or restart Dave Thaler (DT) - On the agenda, it should JK's presentation before this. Was there a bash? MC - Let's go back to JK's presentation 3 draft-ietf-mif-mpvd-ndp-support (Jouni, 10 min) A short update to the draft. In -03 addressed many comments. Now only one ND option, PVD_CO is only allowed in RAs, length of hash and signature added, etc. Size consideration: signatures will grow the size of the RAs, but note that there are no certificates being sent in the RA. They are just hashes and signatures. It is also possible for the explicit PvD information to duplicated implicit PvD options. Tim Chown (TC) - Is there any more on size considerations? JK - no TC - how big do you expect them to get. Is this going to be a problem TC - Since RAs can't have fragmentation, this seems like a problem. DHCP doesn't have these problems. JK- I think that's in there. If it's missing, I'm happy to put it in DT - If the other draft for PVD ID is blocked on clarifications, is this blocked as well? Also, the ID draft has many types of ID types. MC - This solution doesn't actually require IDs explicitly set. JK - We were quite confused what do with the ID document, so we're not sure what to do with it DT - But this document still explicitly uses IDs MC - I think we are going to rethink this based on the last meeting. There was unresolved discussion. JK - To the option of DNS to get the name, I don't want to have to rely on DNS being around. So, our document does use the PVD ID, but we hope that the ID draft will be updated to be cleaner and a smaller subset. DT: That sounds like a good answer, I think JK's "only use UUIDs as ids" would be a fine answer. TC - I think it's worth mentioning that RA's can't be fragmented in the document (RFC6980) while DHCPv6 responses can be. JK - (explains the PVD_CO option). At a minimum in can just have the ID, with no configuration details. The ID can be 'whatever'. Ian Farrer - Has this been discussed with 6man? There is some push back on changing RAs JK: Haven't brought it to 6man because the working group hasn't stabilized around this Ian Farrer - So the general way forward is to figure out what we are doing for this, and then send it to them. MA - There is a use case for having a PvD that non-PvD aware devices don't see. We do need a discriminator that hides the info from some devices. If NDs and RAs are locked down, we need another method. DNS-SD is one vessel, we could have unicast ND, or HTTP, etc... And then you are duplicating this RA mechanism. There is no consensus on where to go here. JK - If this won't progress, please tell us as soon as possible. DT - When I read this version of the document, I tried to have fresh eyes. I was confused about what would happen if you have an option that is both explicit and implicit; the answer was only in the appendix, and should be added further up in the document. JK - Some of this was based on the mandate to not define the host behavior. DT - The other question is what the way is that 6man would accept this. Maybe this discussion should go to 6man sooner than later. JK - I'm happy to do that but the group needs to decide what it wants. 4 recharter discussion Recharter text tries to reflect what we are actually doing now. Define how devices behave with multiple connections (multiple networks, portions of network, virtual networks); handle problems that arise from multiple networks; define the PvD architecture. The three remaining items are: how explicit PvDs are configured, how to get more information about the PvD; and what an abstract API around PvDs looks. What do we think about this? MA - To be clear, are we also defining the properties that we discover, not just how? MC - Essentially yes. But do we want to have a charter? TC - Yes, if we want people to come here. We do need an API though to work out. Ted: home net is quite likely going to ask for help from mif. It's nice to have a group here. MA: DMM wants cost in properties; that should be owned by MIF Tommy Pauly (TP) - There are other working groups that think MIF is working on this; for example Captive Portals needs to solve this same problem. MA - Other people should be bringing things here. Someone needs to be looking Sri Gundevelli (SG) - I think that other working groups should be defining the prefixes TC - I made the point about captive portals and MIF at the original captive BOF. The question is do we have one or more networks, etc. It's applicable even if there is just one. Ian - To Sri's problem on defining properties, I agree that the properties do belong to other groups, but MIF should define the format for communicating these properties. JK - Agrees DT - Two sentences from RFC: "DHCP6 and RAs are the most common ways to configure. To do MIF, these must be extended." Do we still believe this? MC - Right. Lorenzo didn't like both DHCP6 and RAs. DHCP has a problem with IPR. RA will have trouble getting through 6man. MA - I think the answer is that we don't believe it TC - You could have an RA per-pvd, this might solve the problem DT - TCs queestion is something that needs to be made by 6man MC - We could also take the ID out of the DHCP draft and see if the IPR still stands. DT - A lot of this needs to be a discussion in 6man. And sure, we could have 15 drafts and see which one gets IPR against it... MA - 1 way forward would be to ask 6man to help us solve this. MC - do you want to write up some text, sense of the room? MC - If we could get consensus to do that, that'd be great. Ian - Absolutely, involve them sooner rather than later. JK - Multiple groups have had extended ND options, that have been fine. Mobility got approval from 6man. MA - Are you asking for consensus on an ND draft first? JK - Yes, essentially. We need to know what we want to do. MA - It's all about the approach. We can go more informally, and work it out better. TP - Let's just send a pointer to the current draft to 6man and get a quick review of what they're interested in. MA - I'll write something and send something to the list. We can iterate. MA - To get back to the discussion, we've talked about the charter details, but not the higher level options (charter, hiatus, close) 8 for recharter, 4 for hiatus, 0 for close. One problem we've had here is a hard time with consensus and engagement. 8 people say they will do work. Same number as rechartering. We're going to ask for the same question on the list. DT - I'm not sure there's much difference between hiatus and closing. They seem equivalent. SG - That was my reading as well. MC - We're just trying to get a feeling for what's going on Terry Manderson (TM) - There's 3 key points: 1, The problem on the RA space, if this comes back negative it's a blocking point 2, The amount of resource that poeple have to work on this. There's only 20 people in the room 3, Experience - what's out there and being done. Some work has been done. I'm not sure that there is a strong community out there These are the things that I will be considering MC - How many poeple here are working on PVDs? 5 We'll take that question to the list TP - I think we should focus on the practical use cases--like captive portals, etc. Things like VPNs and Cellular APNs have already solved these problems in their own protocols. MC - Other use cases - VPN - what should go over the VPN TP - a lot of the VPN protocols have solved that for themselves. On the VPN side it's more of a solved problem Captive portal might be more of a interesting question HD - Do you consider multiple APN a use case? TP - I think that this is already solved. We could share hest practices. It's more of a solved problem TM - Tommy made a fair point - there's work that you want to do. I ask the WG to look inside and ask if the work that you want to do belong here. But does this mean that we should do the work here in MIF, or does that belong in another group? DT - I'm not doing work here. I raised my hand several times as there are multiple options that I would be OK with as long as the work gets done. I don't care where it gets done. DT - I think other groups can help with this. MC - It's been my experience that when you close a WG, you take every item and find somewhere else for it to get progressed. MA - There will be a draft publised in the next few weeks on implementation experience for Linux. It may be a solved problem for Android, but it's not for desktops. How the OS does this is what we've tried to get done. MC - While it's clear that RA would go to 6man, what about v4? MA - For v4, it would be an implicit PvD TP - We don't necessarily need to have a consistent protocol for everything, but it would be very useful to have a well defined vocabulary for many of the new properties that will arise for dealing with PvDs. Ian: The conversations get extremely hand-waving, which is a problematic. Maybe attacking this from both provisioning and protocol simultaneously may be helpful. 5 MIF related documents 5.1) Homenet naming architecture document (Ted, 10min) Presented this initially to home net. If you look at an Android phone, it's able to do MIF because it does a per-interface mapping. But in a home, the devices aren't connected to the multiple networks directly. This becomes harder. Home net assumes that home nets are multi homed. They have multiple PvDs by definition. There are n+1 provisioning domains, where n is the number of external networks. DT - If you have a guest lan and a non-guest lan in your home, do you have 2 pvds TL - You could say that there are 2 implicit, but you wouldn't be connected to both DT - It's probably likely to happen more than some other things homenet supports TL - You just made my life harder DT - Welcome to MIF :) MA - Would you include the PVDID in every query? TL - Correct TL - Devices may want to get back to the home network, which then makes the home network an externally accessible PvD that you access through a proxy. There is not technology to query for multiple domains, so I came up with a hack. Every domain has its own name resolution server, which defines the provisioning domain. There is at least one IP address for a DNS server per PvD. We would use the PvD ID in every query, etc. TC - Do we think that HNCP can help in the home net case? It says you can get info about its connectivity and circulate it; can the same be done with the PvDs? TL - But not to hosts TC - HNCP would config the routers and RAs would send it to hosts EV - If you go to a single resolver, then the resoler doesn't know where it's coming from TL - It's good to have a local IP address to use MA - If you're running a seperate instance, you would have a seperate address space. TL - you would have one resolver listening on different sockets, on for each address space MA - why do you need the EDNS0 TL - It's not needed. I wanted to see if the WG thougt it was a good idea DT - I don't think this idea is crazy; but to clarify: you're saying we have a home router with two ISPs uplink, and has four IP addresses--two uplinks, and two internal addresses. This means it has 4 PvDs, and is listening for DNS on all addresses. It can resolve locally to go between PvDs. If that's what you mean, that seems reasonable. But it seems odd that we'd give out the external ISP address of the router as the DNS address.. TL - No, I'm not saying that the IP address is the external addresses. It may be one or more internal addresses. DT - But it could send the external address. TL - You'd probably want to use ULA addresses actually, in case things go away. MA - So that's four PvDs? Couldn't you have one guest network per ISP? TL - But if they're public they don't need a different PvD per ISP for guests. (Conversation devolves into many clarifications) 5.2) draft-mccann-dmm-prefixcost (John, 10min) Communicating prefix cost to mobile nodes-DMM draft being presented here for information. As a device moves further from the network, it gets more delays, etc. The proposal is that the "cost" of this link can be communicated to let the mobile device decide whether or not to stay on the network. Some devices may want to stay on the network to finish a transfer, others may want to disassociate. The motivation is to get a more optimal route for mobile devices. Slide 4 DT - How many interfaces does MN1 have? JK - They're on one interface, but we don't restrict it MC - It would be nice if MN1 could tell and pick the source address that will use the the shortest patch, but how does this work? Where do those nubmers for the wieghts come from and what are they? Isn't the cost of the path based on who you're trying to reach? JK - that would be expensive to calculate for the end to end. It's excluded The calculation is a gap in the draft and it's a comment that we've had a few times HD - I understant that you get the first cost. How do you calculate the 100th cost MC - AR1 says this link is 200 HD - Who tells that AR1 that it is covering a lot of hops DT - I have a couple of questions. How many RAs does MN1 get? JK - 1 DT - There's only 1 RA, 1 interface and so there's only 1 PVD. Is this a MIF question? JK - I have a use case on the last slide DT - What is the cost of the default route. For any route we have a 2 bit preference mechanism. That's the only value that I see on putting on a prefix is that you have a cost for talking to two hosts on the same prefix JK - It could also be the MN1 talking to the server DT - You could do that using the routing information option. There are 2-bits in that that you can already use [RFC4191] Marco Liebsh (ML) - How do you take the decision on when to deprecate the prefix? JK - Some hosts may be happy to take the higher cost path ML - this could be solved quite simply. Adding costs to prefixes may complicate the whole thing. Slide 5 DT - Based on your previous answer, I don't see how this works JK - It's in the prefix properties HD - How are these learnt? JK - It could be SDN. This is getting in to the DMM architecture Margaret: Anyone have anything else to share? Then we're done