MIF Minutes Minutes: Ian Farrer Jabber: Dave Thaler 1 Agenda bashing (Chairs, 3 min) MIF MPVD architecture ==> RFC 7556 2 MIF WGLC for 3 weeks (Chairs, 5 min) 2.1)draft-ietf-mif-mpvd-dhcp-support 2.2)draft-ietf-mif-mpvd-ndp-support We need 4-5 substantive review 2.3)draft-ietf-mif-mpvd-id MC - any Volunteers to review MIF PVD-ID, DHCP and NDP drafts for WGLC? Eric Kline, Ian Farer volunteered. MC - Comments on the m/l list will be discussed in WG today if / when the authors appear. 3 MIF MPVD API design (Erik Kline, 30 min) Ian Farrer - What is the concept of the default PvD that you've implemented response missed MC - When we make the API, no app will call it. in my opinion when a PVD isn't specified, then the stack will - EK - It could be like trying to cnnect to the unspecified MC - Then it wouldn't connect Suresh - I mostly agree with margaret, but calling it unspecifed doesn't alway result in the same behavior as today Steven Barth - you said there was default, when is this determined? EK - The app makes that call SB - if the app it doesn't make the call then its' when the socket is created EK - It's when the source is selected, once the source is selected, you're committed. SB - Sometimes it doesn't if it's a UDP socket then it's done each time I send a packet Daniel - from what Margaret said, I think it's a must have. You can't expect application to work less well than today. You have to continue support for existing apps. MC - I don't disagree, but that's an implementation issue. You could change the implementation with every Android version and that would be compliant with the sockets API. EK - what I recommnded is that undecided is undecided until a decision has to be made. MC - if the interface is in more than one PvD, then you have to make the decision. You might have to do a src addr selection then a PvD selection. You could be making a secondary choice if there are two PvDs on the same prefix EK - Both would be implicit. hmmm. Mw - Once you've chosen the src addrs, you've chosen the pvd Mark Townsley (MT) - You shoud also be able to bring in new devices with a new function as well as supprot the old ones. You might want a vm that is pvd constrained Lorenzo - You don't have enough information to select a source address and tehn pick a pvd. You pick a pvd then an address MT - we should be able to provide that information MC - I agree with LC for PvD aware apps. Fon non-pvd aware apps, they don't care. They want to go to an address. Lets not specify how the system chooses it. LC - Ee tried it and it didn't work MC - Todays applications don't have this and sometimes they work and sometimes they don't LC - let me elaborate on why it didn't work. We evaluate a connection for internet connectivity and if it didn't have it it stayed in the background. Then we tried routing tables, which worked until you tried connecting to a URL and it didn't work. You need to know the PVD before you do the source address selectino. MC - I see what you mean, but we should leave this out of the sockets API. SB - Would it make sense not to hvae an explicit PVD selection, to have an atrributes selection - i want low latency EK - What you're asking about is implemented in this stuff. The app can ask what the bandwidth attribute each pVD has MC - I would argue that bandwidth wouldn't be a property of a Pvd, it could span multiple interfaces. It's a per-prefix attribute. SB - Does this mean that we need another attribute for requesting bandwidth. MC - There are lready ways of doing this. There's no such thing as the bandwidth of a PVD. EK - You could query the PvD to interface mapping and use that to find the bandwidth. MC - You can't say 'one hop away tell me how fast you are' EK - You can always construct a situation that this can't answer LC - I think you've hit the conceptual boundries of the concept. It's meant to avoid config errors when you've got multiple sources. There's not enough information to select this. MC - You could use RAs, but no-one's specified this. LC - There's no way specified to do this. PvDs doesn't answer the question. PvDs aren't going to help you. Marcus Sternborg MS - Is corrcectly defined if I don't get any benefit from it. I still need to use a load of hacks. MC - The pvd gets you better service in the case that you have no service at all. e.g. the wrong DNS server. If you want to knwo about the interfaces, look at the interfaces. But that doesn't tell you about the rest of the link. EK - You mihgt have one interface adn a VPN on that interface. MS - Multiple prefixes with MC - This could be useful for multipath TCP MS - You could select any PvD MC - Easy to say, but hard to define MS - Happy eyeballls 2 FTW! MT - There needs to be something common between the provisioning that the applciation can see and the network can see. the prefix achieves this MC - This is a problems when I have IPv4 and IPv6 on the same interface MT - Can we provision out the v4 into a seperate PVD? LC - No, the dst could be dual stacked MT - You happy eyeball the destination LC - Then the app has to find 2 pvds MT - Then have a PVD group above it. MC - We're talking about an architecture doc that's already an RFC. We can't make an API that assumes the architecture is different to the architecture. If you think it needs to be changed, then write adn tell us. MT - The 464XLAT case, the network sees it as EK - Separating out v4 would be worse in this case. LC - A large part of RFC6724 is sorting between v4 and v6. Even when v4 is dead, you have to teach the app that 2 pvds are the same EK - Let's not have meta-pvdss SK - It's a choice of what the operator advertises. If you want to group v4 and v6 then you can, or you can separate them. You can isolate v4 and push it out of the way. EK - We push that on the app. If the app wants to try, then let it. Dave Thaler (DT) - This is the first slide that's talking about the socket API - there needs to be ... MC - We would need to re-charter to include this DT - some of these calls are deprecated by the POSIX community. We should talk about the MIF api and not the socket api, but I think we can mentally translate these. MT - You need ot discuss this with the qick guys -- response from EK missed MT - Very happy to see this work MC - There is one question on how to go forward. should we ask if we can specify a sockets API (it's outside of the charter) DT - The charter says we should be doing an abstract API. If you ask and the answer is no, then it's useful work. I'm not in favour of doing it here. I think the best idea is to specify the architecure and an abstract API then pass it to the BSD people. It steps on the toes of another SDO MC - In the past we've written an informational sockets API and the other SDO. We end up with a info RFC and they produce an ISO/IEEE. We kick off the work. I don't know of a different process. DT - There was a case of this that was done with the Austin group. EK - Do you have an RFC number? MC - Should we write an abstract and a sockets, should we only wrtie the abstrat, or don't you care? DT - I think that the value of the abstract is that it can be used with other languages than the C API. You're right that the IETf has traditionally done info RFC. I don't object, but it's out of charter at the moment. The challenge is if implementations start to implement this using the bad version. We had to do a lot of rework in the past due to this. The risk is that we don't get the the socket api. It's whether it's done in the right timeframe Terry - Putting on my AD hat, I'm saying follow what's in the charter. You don't need to do the lower level stuff yet. I don't think documenting the socket api at this stage is ... MC - Is the goal to have a sockets api or you don't think it's useful? Terry - Maybe eventually but not at the moment LC - Dave said if you do it now, then it might be a problem, but you fixed it. You can't design an API without an implementation MC - We've had a lot of problems with the abstract API if it's not low enough level to be useful. A sockets api allows you to be grounded in at least one language DT - I think you're worried about time. I think we should send a liaison to the POSIX community to work with on this MC - That sounds good. Terry - I concur with Dave. That sounds like the right approach. MC - If we're going ot be building an api that people are going to use then we need poeple who want to work on it. LC - POSIX doesn't work on stuff, they look at what's been built and choose from them Terry - This is a meta discussion, you need to take it offline LC - To clarify, we should work on stuff and pass somehting substantial MC - We should start working on something so that it's grounded without a target for publishing it as an RFC or sending it to POSIX. Should we start working on this in parallel alongside the abstract API? MT - We can mandate from the bench that ther will be six implementations in six languages, but at the end of the day it's down to what people are willing to implement Ted Lemon (TL, remote) - suggest using the term 'concrete api' instead Terry - Based on that, do you need a hum as it's in the charter? The concrete api is to get some experiecne for the abstract API MC - If you want to work on the concrete API then email me. It's not a design team. DT - one of my jobs is liason to the C++ standardisation people. There's no official liason, but I'm happy to be kept in the loop to put people in contact. That's the Austin group. IEEE, ISO and someone else?????? MC - We'll talk to you offline about getting in touch with the POSIX people LC - The concrete and abstract api people need to talk to each other MC - Who would work on the concrete API 9 hands raised MC - We'll figue out how to get the concrete and abstract api people talking 4 MIF MPVD Homenet (Geng Liang, 10 min) draft-geng-homenet-mpvd-use-cases MC - We don't standardise Homenet. The idea is to get an idea of what we need from Homenet so that we can take it to them. Unknown - Why can't RAs be used for this. Why do we need another protocol MT - The homenet architecure has hncp distributing the prefix - you're redefining how homenet works Unknown - Let's take it to homenet HD - There is a homenet router Ray Bellis (RB) - If we could do all of this with RAs, then we wouldn't need HNCP and we do need HCNP. MT - It would be easy to take the info from the ISPs and hand it to the host. At a high level it might seem like it would work, but there's cases that need to be considered. MC - Should we define the TLVs here and take them to homenet to be standardised? First consideration is if we can use a container. MS - If this stuff was per-prefix, then it would work automatically, but it's not. That's why there is the need for more control. The MIF stuff complicates things. It needs to be specified before I can implement it. SB - I think you're using OROs to determine if the client can receive it. How do it get redistributed betweeen different clients and protocols. Is the edge client capable of that We need legacy info that is not in a container and also the PvD container, but only giving these to routers that support them. It's awkward. SK - How does hncp to dhcp propogation work? It's a more genral problem than pvds SB - It needs to have both the legacy and the pvd aware. That's not needed for anything else at the moment. SK - It's not a single thing. You either ask for what you know you want or a superset of everything. MC - I don't understand the problem - the only thing that would be held in the container is the pvd name MS - There's also authentication which is assumed to work magically. I won't work on it if no-ones going to use it TL - I think that we want homenet routers to be MIF capable. It might be the wrong thing, but it's not obvious. MS - Whilst there's hand waving, I'm unhappy to do any work on this. MC - We have some docs that are RFCs. What time are you waiting for? MS - I'm waiting for a client and a server so that I have something to test against MT - Even without the spec, we can sit down and work out how it's going to work MS - At this point I think it's premature to say that homenet has to do it MT - Homenet can work on this. if you implement it is up to you TL - It should be clear what we need form the architecure. homenet doesn't work well without mif SB - There may be additional requirements on the DHCP server, but this doesn't concern HNCP as much as the generic dhcp spreading mechanism MT - For some things it's transparent for some it's not. you might take a prefix and carve it up. There's stuff to think about. SB - HNCP can pass DHCP options, does MIF need this as well SK - The mif dhcp option can be transported with this, but how do you transfer an ORO? SB - Then the edge router has to pass the ORO on behalf of the client. Is the specific oro significant for the client or is it something that the network wants? SK - That is a tough problem TL - The routers need to come up with pvds themselves so that they can work with providers that don't support pvds MC - We'll discuss this after the meeting. Terry - AD hat - It's really important that this work is done. There's a lot of enthusiasm in the room, but there's no work on the mailing list. Please consider the amount of work that goes into this in the room and on the m/l. MC - I think that the reason we don't see a lot of activity on the list is where the documents are at the moment.