Detecting Network Attachment (DNA) BOF Meeting Summary: ================ Summary of the DNA BoF Meeting IETF58, Minneapolis, MN, USA Tuesday, November 11 at 1545-1645 * Text (Contributed by Ted Lemon) of the meeting discussion is available online at: http://www.ctie.monash.edu.au/dna/minutes58dna.txt Minutes. ------- Introduction by Greg Daley Session Chairs: Greg Daley (GD) + Pekka Nikander (PN). GD: Status reports - for proposed charter items for detecting network attachment. DNAv4 Looks like it's gonna be in DHCwg. - we'll have an update here though. (Presentation by Bernard Aboba) DNAv6 Problem Statement coming up, but not in repository. (Presentation by JinHyeock Choi) IPv6 DAD Optimization Goals and Requirements out. (Presentation by Daniel Park) Link layer hints - Paramters for L2 Hints (Presentation by Nicola Montavont) Link Layer hints for DNA (Presentation by Alper Yegin) We'll have the discussion of these two together. JinHyoeck Choi (JH): DNA for IPv6 problem statement presentation (Talking about movement detection and existing problems in Mobile IPv6. Then DNA for IPv6.) Bernard Aboba(BA): Why use network unreachability, why not send RS/RA message immediately? We do this in v4 because we don't have RS/RA. JH: If you have two routers, this could cause problems if the wrong one answers first. GD: Answer: this was defined as the reachability test in RFC2461. Also mentioned in MIPv6. ???: What is the reason for that? if you have 50 users on an access point, it goes down, comes back. There have been extensive discussions on this. First check new link, *then* do RS/RA. Bernard Aboba - DNA in IPv4 presentation issues list is at: http://www.drizzle.com/~aboba/DNA/dnaissues.html. Ted Lemon (TL): What about hysteresis? GD: We should talk about this on the mailing list. TL: Use a well-known address for source? GD: Not convinced that's useful in all cases. Could use one of the reserved IPv4ll addresses. James Kempf (JK): Bernard made the point that hints need to be verified. In GPRS&CDMA2k, my understanding is that if you get information in those networks it doesn't have to be verified, because the network controls where you are going, and if it tells you something, it's not wrong. 802.11 is very different. Very little indication of how to map to the IP layer, it's very complicated. I think movement detection is a kind of a misnomer because you're really moving at layer two, and your routing's changing or not at layer three. So you're trying to detect routing change, or need to take action to change routing (mobile IP). So in first two cases you can use info in these triggers to reliably determine whether you need to change your routing. In last case you need to probe, etc. Speaker???: Trigger just says your link has changed, layer up has to determine what to do next. ???: PPP link going down/up in CDMA2k is reliable indication you have to do something. BA: I think there's a distinction between indication that something's changed, which might be reliable, and indication that you have meaningful layer three connectivity. You get an IP address, but you don't have reachability. Helpful for multihoming case. ???(same): There might be two ppp links of interest, one between laptop and phone, other between phone and network. Greg: There's a distinction between routing func and ppp func. We have a bof which has a fairly diverse set of goals. Looks like DNAv4 stays in DHC. Can DNAv6 be a goal in itself? Does DAD optimization belong here? I think there's interest enough in link hints to do a catalog. I don't think there's a lot of reason to go deep into abstractions. We might just be doing the wrong thing. James Cabgan(JC): I think one of the problems with this whole topic area is that IETF can't solve the problem. Problem is in 802.11, which doesn't give host enough information. I think the problem is that if we start a WG and from the get-go it's apparent that the most difficult part of the problem is something that we can't solve, it's kind of setting ourselves up for frustration. So it's important to know what part we can't solve, and not try to solve it, but to instead focus on the part we can solve. Thomas Narten (TN): Agree with James to some degree. This business of link hints is potentially useful to catalog and describe so people understand it, but ultimately the stuff that goes on in L2 we don't have much influence over. We can determine if we are on the same IP link as before. If we can make improvements there, we've done something positive. ???: The link hints problem there are other parts of IETF can benefit. Agree it's hard to solve. If you take fast handoff work, I think that the link hints is a very critical piece of the solution, particularly handoffs across different types of technology. Would be good if IETF takes an approach. Depends on how you scope the problem - create an abstraction that doesn't depend specifically on IEEE stuff. Work is very useful. BA: Part of the reason nothing's come out of it, you have to look very closely at the application. For TCP it might mean something very different than for DNA. In particular, some of the discussions Greg has been having, what are you proving? I think it's relevant. It doesn't take an enormous amount of effort to answer the question of what to do with each hint. RAID or signal strength. TN: One thing I do get a little nervous about is when people say L2 triggers or hints are critical to making this stuff work. ???: Proprietary mechanisms of detecting triggers can be developed. Question is, can we have a standard way of doing it? GD: Quite possibly correct--we're the puny weaklings. But talking to IEEE and knowing what we want does help. ???: Is there a problem in talking to IEEE? GD: I think we can do it. Whether DNA is right group I don't know. TN: Wary of IETF trying to come up with consensus on what to tell IEEE in this space. Easiest way to make progress is to just go over there and make the arguments. GD: Can we leave comments to those who are standing up? Brajesh Kumar(BK): 802.11 could use for any technology. PPP establishment is a fairly strong hint. So even if perhaps we get no strong hint from 802.11 now. If we can articulate the problem there maybe we can be more useful in that context. We should not be scared of any of the problems just because we have no mechanisms from link layer yet to resolve them. James (Caghban?): Bernard and I are working on stuff with IEEE. Situation is that right now as you have described it's pretty bad with 802.11. 802.16 nobody's looked at. 802.20 is coming. Whole list of possible protocols that might need some work. Obviously IETF is not going to get into that. Somehow we have to figure out some way that they can get their process to deal with it. We did this quite successfully with 3gpp. Would like to do something similar with this. BA: There's ways to go about this. Instances where IETF has been able to give guidance. Pilk - advice for link designers. If someone were designing a link in the future, might help. Having been in sessions, not sure the help we'll provide will be worse than the disease. They're looking at a whole bunch of things including changing the IETF's use of triggers. Important to tease out fundamental principles, don't need to characterize everything. GD: Opinion on where IPv6 DAD should be done? TN: I have opinions, but at some level either group could do work, it's a management decision where it's got best chance of success. The high level bit is that this problem needs to be solved, we need to give it a home. GD: Ask room? PN: I guess if we are going to ask room opinion we need more background. TN: Then we should just go on, maybe - might take too long. ???: Are you talking about defining requirements? GD: Idea was that there were at least two drafts which would be pushed forward at this time try and get some idea of the goals or requirements and get a candidate DAD optimization spec. Any additional stuff if there's different properties we can have a look at those. At least get something to go towards standards track. People are screaming for it. TN: My assumption is make sure we have a clear problem statement, and we develop a solution in the standards track. PN: Here's a brief summary. I think there are two major issues. One is IETF ask for working group, we really should focus on IP layer. We should not go too far to link-layer issues. Second thing, there is pretty strong interest in these link-layer issues, definitely a need fro some kind of liason to IEEE. Whether it's a WG job or belongs to some other part of IETF needs to be clarified. If we are progressing towards WG, safer way is to focus on IP layer issues. But both should be addressed in some way. ???: Might be useful for wg to catalog what hints might be useful, give it to whoever goes to IEEE. ???: One thing on link layer hints, no other group looking at this issue. Main user of those hints will be the DNA group, I think those drafts are very useful. We have to not only catalog all those hints, but what use they are. Speaker: Two parts - identify what is out there, how we use it in DNA. Second, what else could be helpful? Falls beyond the boundaries of IETF. If we are not going to do the first part, are we going to completely ignore what we can get out of link layer? Purely network layer? GD: I think there's ways of dividing this sort of work in network layer. ???: I think that even if you cannot change what is being standards, you can leave implementors some guidelines on how to implement interaction between link two and link three. I think the point is not about trying to change what we are doing, but trying to abstract some guidelines. GD: We've got to wrap this up. Please get on list, say if you want it a WG. Input in charter needed, or you will get a bad WG or no WG.