Meeting : IETF89, Thursday 9:00 - 10:45 Location: London, UK Chairs : Magaret Wasserman, Hui Deng Minutes : Ted Lemon ============================================================== Agenda 1 Agenda bashing (Chairs, 5 min) 2 MIF architecture (Dmitry Anipko, 20 min) draft-ietf-mif-mpvd-arch-00 3 MIF API (Dapeng Liu, 5 min) draft-ietf-mif-api-extension-05 4 Proposed New Works 4.1 draft-kkbg-mpvd-id-00 (Shwetha, 10 min) 4.2 draft-kk-mpvd-ndp-support-01 (Suresh, 10 min) 4.3 draft-kkb-mpvd-dhcp-support-01 (Suresh, 10 min) 2 Dmitry Anipko MPVD Architecture MPVD Architecture updates and re-cap. Ian: confused about how default provisioning domains are defined. Dmitry: is there a better way to do it? Currently we don't have a way to know that the config information is coming from two sources. Margaret: the software might know something about the interfaces. So we don't want to require that all implicit PvDs are 1:1, but by default they should be. Ian: I'm thinking around the hg(home gateway) example, internal and external interfaces. For a hg, might have several use cases which are internal, woudln't want them to be different PvDs. Margaret: The node has some additional knowledge about the topology it could use in deciding how to organize the implicit PvDs. -- LC: I really like this document, hasn't generated much discussion that it answers so many questions in such a good way that there's not much to discuss. If you actually think about doing this, it turns out that most of the implementation is straightforward. The only question that I saw is what happens when I have an application that's listening to all addresses, what should happen there? If we put it into a PvD, what happens is when stuff comes from outside of the Pvd, we have to figure out which PvD it's on. With multiple per interface that's not easy. If you put listening socket into PvD, that's a lot of burden on the app. Current apps bind to ::. One socket per PvD? And then with UDP and IP_PKTINFO options, etc. Listening apps and UDP are not necessarily that cut and dried. Margaret:that's a really good point. Dmitry:I agree with your first point, needs to be covered, I don't necessarily agree that it forces app to become multiple focus. You can have a socket which works on multiple types of PvD, in some cases may be desired, but not in 100% of cases. LC: let's see if we can clarify by example. We have a node that has Wifi and 3G PvDs. I'm an app, don't know anything about this, call "bind to :: and listen." If I put that app into one PvD, say it's WiFi. What happens when it receives a syn from the 3g interface. RST? Does app have to create more listening sockets, one per PvD? Dmitry: If app is explicit, then yes, we'd drop. You can also think of applications as per outgoing case where both PvDs are allowed, in that case I would expect the scope of the socket, it's easy, we know on which IP address and hence which PvD, hence can reply in same PvD. In UDP may be more complex, there is no hard binding between incoming flow and outgoing flow, may need more thinking. LC: for connection-oriented it's easier, but if you want to listen, the system does have to be able to put a particular socket, once you've called accept, has to be bound to a particular PvD. Would be nice to cover this in the doc. Another thing that gets complicated quickly. If you use this for VPNs, you've got all sorts of security concerns that are rather fundamentally opposed to what you are trying to do here. If you talk to a security person about a VPN, if the VPN is up, device must not be connected to anything else ever. Margaret:if you are talking to a bad security person. LC: as a known security guy, I've got a VPN, want to print on my printer, the security guys say no. Dmitry: split tunnel, As far as this text, doesn't contradict. Only introduces a tool, how you can implement different behaviors is up to you, that's a policy question. It enables implementors to do it in a cleaner way if you want. LC: not so much security considerations as figuring out how to implement when you have multiple policies. Margaret:there's no notion that the conceptual notion of a PvD stops you from shutting down every other interface. They aren't connected. LC: it's just that this when you think of the VPN scenario, on first sight it completely matches the PvD. But it turns out that the VPN has a special property that this PvD might want ot be able to disable other PvDs. Dmitry:this provides a tool for implementing numerous scenarios, but doesn't specify how. LC: would be nice to say here or elsewhere how to use this tool in that scenario. Marcus Stenberg: it seems to be very interface driven, as a homenet guy, I see that we have one or at most two interfaces, might be connected to multiple ISPs, so you wind up with different PvDs. We can provide explicit PvDs, but may have prefix-specific and interface-specific, how that maps to clients that work to homenet... would like to see some text on that. Keith Moore:there's a very large camel attached to this nose. We are abstracting this configuration info that might be if specific or not, but at the same time I've lost count of the number of times I've wished as an app programmer that I had a name for a particular chunk of network. There are various reasons why IP address prefixes don't do it. I have a feeling that once you start building things like this, others will want similar things that aren't quite what you've defined. A little bit of foresight might be appropriate. Dmitry: to make sure there is no miscommunication from the draft, if you read through the draft, proposed ways to implement, you will see it's a container for information that already exists without PvD. If somebody else needs different type of information, but same approach, if the approach works, easy to get other information in. If approach doesn't work, it would be good to know why you think so. Use cases for which this doesn't work, that would be very interesting to know. But if you are just talking about different elements, e.g. sip server address, can easily be inserted into PvD. Keith: I have a problem with defining it as a container, or a collection of data, might be easy to fix, add a distinguished name to the data. Margaret: we have a whole presentation on I-Ds that are going to be about names. LC: key insight here, when you are connected to one network, that's engineered to that it hopefully works. If they are providing you a service, if you do everything they are telling you to do, it's supposed to work. The network expects you to be connected only to them. So if you want to connect to multiple networks, need to partition into a set of networks. So you need a container, a split-brain model. The idea was let's group that info together. If you use weak host model it's all in one big pile, pick IP address from one ISP, use it on the other, doesn't work. Idea was do a minimum, give unto Caeser, separate the two masses that you have, this is minimum to solve problem. Keith: I think you need to look a little deeper, I will send text. Other concern I have is promoting balkanization we've seen, would like to see some work about trying to treat portions of networks as different. That's bad enough already. Margaret:that's the world we live in. Keith: because reality exists we need to further encourage. Margaret:if the entire network were all the same, no reason to have different interfaces. Keith: effect of what you are doing will Dmitry: general feedback is that people feel there are areas we need to address, but I wanted to walk through some thoughts which I have done. (this is the Path to WGLC slide) MRW: how is pvd propagated, I had viewd PvDs as something that is created by each host based on its own interfaces, and then when you asked this question it brought up the question about what homenet is doing, if there are two isps connected to one network connected to one home router. How do hosts behind that know that they are connected to two networks? Dmitry: the digital signature used by identification of the content, but is the home router creating id for home house. Dmitry: not talking about propagation from router to host. Is there info from ISP to home router? Is there anything there mpvd specific? Or ony legacy mechanisms between home router and ISP, home router can use one which permits notion of container. Mark: what about the case where there is two ISPs with different charactristics, 3g and wired, fifi is not always wifi. Dmitry: this network has such and such host characterics, bandwidth. Mark: if I receive ... should be considered cell phone. Suresh: I think yes, there is some stuff send down from the ISP, the PVD info is reason like everthing is coming from source of config, not home router, they are only thing that can guarantee that that's coherent. Dmitry if that is the case, we need to address what does it mean for the keys in ND. What is mechanism that bridges channel with ISP into ND. Protocol? How does it happen? Suresh: from ISP towards home router, not ND, other than when HG is host towards ISP, usually there's DHCP. Dmitry: not clear how that could happen. home router could get permission from ISP propagate into home. Keith: is there a need to have an explicit heirarchical and inheritance relationship between pvds? Dmitry: this has already been discussed, we concluded we couldn't do it, but if you come up with specific reasons it's required or there's a way to do it. Keith: depends on if you need to authenticate. Dmitry: we concluded that we might need to authenticate, but doesn't need hierarchy. Keith: you don't want to standard bad practice if it's common practice. Network might feel it can dictate to host how it's supposed to act, but that's really dubious. Shouldn't be dictating policy to hosts. Dmitry: I agree, draft doesn't dictate host behavior, just provides tool where network information can be communicated to host. Keith: slippery slope. 3 MIF API extensions Margaret: need some more stuff like ask what PvDs are present and what do we know about them? Other than that it looks good. 4.1 Schweta Bandhari, identification of provisioning domains Ted: what if I want UUID and human-readable name at same time? Schweta: define a new format Dave: app might say I'd like to use PVD, here's the ID. Comparison rules, something that comes from API, something that comes from wire. Need to be explicit about identifier comparison. UTF8 string. Case sensitive? True for just about everything on list. MRW: I have a couple of issues with this doc, we discussed earlier, one is that I think Ted asked what if he wants a string and a UUID, human readable string, could be globally unique, I'd take that out, if it has quality of global uniqueness, could have NAI, if it's generated by domain name, that would work unless you need to create a PvD and don't have a domain name. I'd like to see us get down to where we have one type, and some part of it was human readable, one of the purposes of these is as a last resort to present to the user and let the user pick. The idea that user will pick between two UUIDs is mistaken Com.tmobile.blah are human readable and wouldn't be hard. UUID doesn't meet that criteria at all. Ought to be able to narrow down this list to some that have human readability involved. Schweta: for machine readable pvds, may need to generate not human readable, could restrict it to subset of types, unless able to agree on single type, but format could be flexible so it could accommodate a new type. Suresh: if I understand you correctly, you want id types gone, want globally unique. MRW: human readable string plus GUID. That's what I think. Suresh: practically speaking, human readable doesn't always mean globally unique. MRW: should be one type, all identifiers should have two fields. We should agree how we generate the globally unique part. Suresh: anecdotally, in a group of three, we couldn't agree on one thing to put in. Depending on who's providing PVD they have different ways of doing things, think one is worthwhile, but we couldn't agree internally that we could pick one. Worth exploring for sure. Keith Moore: MRW, I agree that we need GUID and optional human readable name, however if users have to see these things, then something's wrong. GUID need to be auto generated. This stuff needs to be self-configuring. MRW: UUID generated locally, etc. Mixing unequal things. Bernie Volz: not sure ID length should be there. Shweta: format is you have ID type and data, length is a property of how it's encoded, outside scope of this format. Dave Thaler: comment on human readable part, who is human? End user or admin? If admin, not in category of what keith is talking about. If end users, not all are the same, can read the same things. i18n, one string, multiple strings, different languages, becomes a protocol issue. mrw: some devices if app can't pick will ask. agree there are i18n issues. dave: open questions here might be better afdressed in arch. do you need to be able to express human-readable? we might whittle this list down. suresh: dave, since talk about comp of ids, here or api draft? Ted: UUID vs human name, need to be sure it's not spoofed. Marcus: if there is no provisioning domain ids, could skip type and length and encode in protocol and would be unique enough that risk of collision would be small. MRW: human-readable name is something like names of interfaces, don't show to users very often, but comes up sometimes, and you can tell them apart. Serial number can't be differentiated. 4.2 Suresh, ndp-support Dmitry: how will work with multiple pvds in same adv? legacy host will go through option, what if it's not allowed? Suresh: exactly. what makes sense to be single is NDU. Anything else we can have multiple prefixes, they all go into the global space. Thing that won't work is MTU. Suresh: prefix advertised goes in container if you don't want non-pvd clients to use it. Dmitry: two ways or just one to define container? If you choose one way may be no way to meet requirements. Doesn't have precedence, may need review from 6man. Keith: I think you're trying to use ND in a way it's not designed to do, probably a misuse. If it doesn't seem to fit, there's a reason for that. MRW: why is this a misuse? Keith: it would take too long. will take it to the list. 4.3 DHCP support Bernie: there may be a lot of signs that could be in pvds, and it seems odd that maybe ND or rtsol will be used to communicate it, but maybe you should just define some container that is not encapsulated for DHCP, that you could use for both. So data can be exchanged either through DHCP or whatever mechanism. "Let's boil the ocean." MRW: i have a concern, there'd be a lot of cases where nodes are configured both by ndp and dhcp, and those could if all one admin entity be info that is part of same pvd, so you might have dhcp handing you some of the config, and nd handling you some, and host discovering something that's part of the same pvd. Bernie: not a complete container, just a way of delivering the data. Suresh: there's some kind of IETF unwritten rule that things are staying this way, not worth investing on the fight, but I fully agree with you. LC: we're going to I think it's useful to define a common format bc you can't use DHCP w/o nd, so if you want to use DHCP, have to put the id into both, or can't correlate, having common format is, you're going to parse the options anyway. Suresh: no alignment requirements for dhcp, technical things that make you require different formats. can't just throw blb into dhcp. We can't throw this into an nd option. MRW: you're also the one who fought to the death to not specify default gateway over DHCP. This is the opposite of what you want. LC: I don't understand if you had a common blob format, you could the most restricted alignment. Suresh: if there's a blob, if I throw it into DHC, need to identfy as pvd container, need a DHCP code point, 16 bits. RA, 8-bit code point. I cannot have the same blob. LC: blob could be interpreted in a common way. For RAs also, you have to since RAs contain information before first option, it's got to apply to stuff outside. Suresh: e.g. def route is outside. LC: router migh be onlt default route for one source addr. Suresh: we can put what's there into option. LC: have to partition MRW: router can send two RAs. Suresh: if I make addr out of prefix from Dmitry: what would be scenario where router adertises pvd but is not next hop. MRW: already do Dmitry: if does want to be next hop, what is harm? LC: might want router to spec which sa Keith: trying to have some pvd info in one place and some in another is going to be too awkward and lead to too many silly states. so you have DHCP options that have matching rules. here is additional information about the pvd that has this prefix that you saw in nd. not duplicating, but matching rules. Suresh: exactly. matching info is pvd id. instead of putting in prefix, just if it came from pvd x is the same consistent domain Keith: I doubt that because data structures in nd doesn't lend itself to associating names to specific bits of info. MRW: we're talking about defining new nd options. LC: to be fair, you already have to do this correlation btw different sources of info even if you have two sources, e.g. two dhcp servers or ras. Keith: fundamental problem we face is trying to make sense out of a situation that inherently doesn't make sense. MRW: what doesn't make sense? Keith: when peopel cite reality, there's a lot of different bad and conflicting practice that this group is trying to reconcile. Make significant changes to internet architecture, disguised Suresh: mobile ip, fixed isp, each route different stuff. mobile costs more money to use, fixed costs less. For one set of prefixes, I use one, for some the other. I need to pass down to host. Unless I pass down to host in some way, MRW: this is all in our charter. Jared Mosch: your scenario is something where you're pushing intelligence into the host and MRW: we are giving them enough info to make an intelligent decision. JM: what you are talking about is something that looks more like a NAT. MRW: we're trying to stop you from having a NAT to hide this from the hosts. If that's what you want, run a NAT. NAT will pick the right set of addresses. If you dont' want translation, have to make right coordinated choice, and you can't do that without info. JM: this is something you can do in hosts today. MRW: have you read the problem statement draft JM: I understand that problem set. Everything I see here is shifting a routing layer, shimming it into the host stack. Keith: the concern I have is yes, you can pass info down to the host. The host isn't in a good position to make the right decisions, app is not, user is not. This is a gap in the internet architecture. I have a problem with the way the group was chartered. MRW: it's really out of scope to argue about the way we were chartered. Keith: you haven't given it enough Dmitry: there was a stong host model. For some scenarios it's not good enough. Doesn't provide much info to host. But this is the same thing. Strong host doesn't cover if you have different networks on the same interface. Keith enumerated several cases, app can't make decision, user can't make decision, you are right. There is no single entity that can make right decision in all cases. Doesn't mean there is no entity that can make decision in specific cases. This is how people deploy things. In some cases the user may know that have internet connectivity through cell provider, and we are fine. We are just providing a mechanism how those entities can implement their decision. Suresh: one thing I want to say to Keith is I do see where you are coming from; host may or may not be able to make right decision based on this, but without this info it cannot. Worst case we are doing something useless. Keith: no, this may drastically harm things. MRW: we're going to work with Ted to put in milestones for these things that are covered by our charter. So we've gotta get milestones for these items, after we get milestones can talk about wg adoption. Will have CFA on list.