G'Day everyone, it's greg here, we're going to try to get the projector working. It's always fun being first up. We'll see if we can get through the technical difficulties, but I think we're going to start immediately I think. So, if you didn't know, this is DNA working group, there's nothing on the screen to tell you, so. And we're just going through some of the documents today. I think the agenda today is 5 minutes of agenda bashing, 15 minutes of document status, and that's primarily the documents we don't have a lot of work to do on right now. We've also got 30 minutes for discussion of two documents which are the Complete Prefix Lists and the DNA hosts document. which we got some feednack from Thomas Narten About. also we've got 50 minutes for assigned for the DNA solutions protocol. Hopefully we'll have audiovisual cues. byt then... At the end of the discussion about solution space, we're going to have a look at future directions, and try to fix the charter milestones. Does anyone have any questions Sathya Narayanan: DNA hosts feedback. Sathya Describes redoing DAD, not redoing DAD on each cell change, and the tradeoffs: "Why do you have to do DAD if you're only disconnected for 10sec/30sec"? Also there's a possibility that the possibility that the collision chance is very low. (James Kempf) JAK: Assumption behind not redoing DAD, is that the cost of DAD is too expensive and if you're doing optimistic DAD its not expensive any more. Basically, the ability for sending traffic from the address isn't impacted, it might result in some additional NS, hopefully no NA traffic, so I guess I don't see that as a problem . The second one, the assumption behind that one is that Duplicate Host identifier detection is sufficient, and there's been a lot of discussion about this in the IPv6 working group, and I believe that the consensus on that was that no, that's not sufficient. And I think that RFC2462bis draft no longer recommends that. If anyone else here is more familiar with that. Vidya Narayanan: James's is optimistic DAD not more expensive or is it time sensitive? JAK: It's not more expensive in terms of having to wait to send traffic. Vidya: How about in terms of signaling? JAK: The signaling is the same amount. You have to send the NS, that's true. Vidya: So I don't know, I tend to agree with thomas here. At least it should be a SHOULD and not a MUST to run DAD every time. JAK: I think a SHOULD is sufficient. Sathya: What is in the text right now? Greg: Just keeping it interesting. So when you run DAD, you don't necessarily have to send the NS immediately. If you're keeping your interface optimistic, it doesn't matter. You might just run DAD periodically, and keep optimistic state, if it's not too expensive for the host. So you arrive on a link which you are not sure whether you're at a particular link or not, and you set your link-layer addresses as optimistic. And you do your router solicitation, and get back a router advertisement. That Router Advertisement indicates whether you're on the same link or on a different link. Now, if you're on a different link, you discard a lot of your old global prefix configuration anyway, and you have to do duplicate address detection. If you're on the same link, this is the case, right? We're back on the same link, we're not sure whether someone's arrived in the period where we disconnected and reconnected, so the question is, what's the cost and what's the benefit? Well the cost is that they've come while we've been absent and have completed Duplicate address Detection, we have completely conflicting addresses. So if we just leave our interface address, our global interface address as optimistic, until we've done a full check, then that is not so bad. And if we keep on moving rapidly, we don't necessarily have to send the NS every time. We can just leave the interface address in optimistic state until we've completed the NS probe. So that's another option. And that has slightly lower costs when there's a lot of movement. If it's not a lot of movement, I think we should just do it anyway. Sathya: In terms of recommendation, I guess it means, making it should instead of must. Greg: Yeah, and may indicate that you want to use hysteresis there as well, and keep the interface in optimistic state. Sathya: Sure. Tatuya Jinmei: Actually, I'm not too familiar with this issue but, I'd like to be sure about the question from james. Are you talking about the consensus in RFC2462bis About whether we need DAD and whether it depends on the interface identifier based on the IEEE address? JAK: in rfc2462, I believe there's an assumption that you can run DAD once on the link-local address if you generate it using the IEEE identifier. After that you can reuse the identifier, in your global addresses without actually having to perform DAD. And I know there was a lot of discussion in the IPv6 WG about that and I recall, maybe I'm wrong, that there was a consensus that that shouldn't be done. Jinmei: That's true. And so basically I think we should do DAD regardless of the details of how the host attaches to the network. But I also tend to agree with greg that if a node wants to avoid the overhead of DAD, so it should perform optimistic DAD. So I don't see any problem with this approach basically. I don't know if DNA specific issues exist or not. Mohan here, so this is pretty complicated I think, why do you have to complicate the situation? it's not clear what we're trying to optimize, so is this case a common case? JinHyeock: Allow me to clarify the problem. Assume a host becomes an idle mode and then comes back to life again. It can use all the previous IP configuration, prefix list, or routers, but, there may be some other host starts to use the address while the host doesn't defend using its own address. The problem is: shall we perform DAD again or not? Two people: We should (I guess). Sathya: That's what we want to recommend Greg: So essentially though, this happens whenever a device disconnects momentarily and reconnects to the same LAN. So, at IETF, in the big plenary, everyone's using their wireless LAN and the wireless LAN connectivity's not so good and (this is in past meetings of course, not this meeting), then you come back on and configure an address and there's a small possibility that someone has configured an address in that interval of time. It's a very small possibility. Are we going to do DAD every single time? That happens. Now you guys know how often that happens with wireless LANs. So do we run the full DAD? probably not... Do we run optinistic DAD? maybe We need to figure out if this is what we recommend. Christian Vogt: Just one quick note: with regard to the signaling overhead, You not only need the NS for DAD but you also need the MLD report, right? Yes, right, and as you said you can also delay that, as part of oDAD. So if you don't do oDAD every time you chnge a link then you also don't need to send the MLD report every time. Vidya: So there are networks where you may never ever run DAD, because you know that your suffix is unique, believe me there are networks, so we can say should and move on. I can't understand why it is such a complicated issue. Erik Nordmark: I think Should is the right word here because if you think carefully there are cases where it isn't actually required, right? It requires thinking carefully. I don't know to what extent we should go into issues in the document about the probability discussion, because it is very different when you decide that you've moved to a different link, where you potentially have duplicates with the population on the new link, and you have no idea what that population is, and in the plenary, and you get disconnected for a millisecond, 3 seconds, whatever. Even if it's a large population there, it has to do with the probability of someone else arriving in that population and picking an address that's your duplicate. And that probability has something to do with how long you're gone. Greg: For any single node, it's O(2^62), right, so it's N times that, because the address was previously unique. So they had to collide with your address. Erik: Yes. Greg: It's a low probability Erik: Yes. I think we still need to go into optimistic, until we've decided that we didn't move, but once we decide that we didn't move, do we actually need to send the NS? Saying well, someone may have arrived and taken the same address as ours, well yeah, if you were gone for half an hour, it might be a good idea, but, seconds, no, that doesn't make sense to me. Sathya: It sounds like the consensus is that we change it to SHOULD. Erik: But I don't know if we want more text explaining stuff saying, well, should do DAD is part of the statement, saying, you have to go into optimistic anyhow, but the question is do you actually send a DAD probe? And I think we can say something more infromative than just SHOULD. We can say well it has to do with the amount of time you've been gone. If you've only gone a few seconds, you don't have to bother because the probability mumble mumble * he actually said those words * If you were gone for minutes, hours, yeah it may be a good idea. Mohan: Should is OK, I think, but then the level of details, I'm not sure about that, saying, 10 seconds, 30 seconds, are you going to come up with consensus on that one? is 1 second good, is 20 seconds good? I don't know? Greg: So the question is, I mean, it's going to very a lot by environment. And one of the things that we found in existing documents which we're breaking the rules of is that when they said SHOULD, they didn't necessarily explain all the reasons why you'd want to do something. So maybe we should leave that sort of latitude for other people in the future. I don't know. Maybe we just don't explain it and just put the should. JinHyeock: One more thing concerns me is that DAD is outside of DNA scope, so is it OK for us to define such a thing? Greg: Yes. JinHyeock: Maybe Jinmei is not happy about that :) Greg: We shall invite Jinmei to review it. :) Erik: So I don't necessarily think we have to pick a number, right? But I think that saying that it's related to the probability of someone else arriving that makes it different. That would actually help people figure out what number should I pick.. Sathya: So I think this is the last issue, from thomas. Which is about retaining the current IP configuration. What breaks if the host send such packets, if there's no chance of collision. JAK: Well, what breaks is the application. Again this depends on whether you believe that the purpose of DNA is to optimize handover and make it quicker, or if in the most likely case you're going to be in the same network. If you think about voice over IP, right, the difference is between these two choices. 1,...,2,3 or 1,X,3. So which do you want your phonecall to do, when you have handover. The first case is where you are waiting until the address has been fixed. the second is where you're just sending and there are drops in the middle, and there's disruption in the stream. Personally, I like the first case. I'd like to have that. Erik: So I was chatting with Jane Hook about this last night. I think there may be different cases, based on the scope of the destination address. So the potential danger is that someone creates state with an address that might be a duplicate, which is similar to the DAD discussion. That might happen in TCP, because you send a SYN, right. I think there's a potential danger, if I'm sending a packet with a source Link-Local Address, to a destination link-local address, it might end up creating TCP state for that link-local connection which I didn't actually intend, because I don't actually know that it's my address yet, because it might be a duplicate. Now this state may affect the true owner of that link-local address, that was there before. So there's a potential issue about sending packets that have a source address which you don't know is unique, when it creates state which will upset somebody else. But if before I move, I have a communication with a global address, global destination, my global source. If I move to another link, i cannot possibly cause a problem for the people on the new link, because it's the prefix for the old link I'm using. So even though my old address isn't valid on the link, my global address is not going to be conflicting with someone else on that link, because htey have different prefixes. Hence sending another TCP packet to that other global address should have no ill effect whatsoever. Yes, the return packets are not going to come back to me if I move, but, so that way you can actually say: yes, in the normal case of global communication, nothing can actually break. If you're using link-local addresses to communicate, you should defer that until you know whether they have a duplicate or not. JinHyeock: I think we'd better make it clear how a host manages it's IP configuration with respect to the DNA procedure. I don't think it's wise for a host to start using its configuration without any constraint. For example, the DNA design mandates that the host moves to optimistic state to use TSLLAO, instead of SLLAO. I think it would be best for the host to just keep the information, but to start using it only after the DNA process is completed. But I don't know if we should ban such behaviour altogether. Maybe we should define it more clearly. Greg: OK. This conversation's been good, but it reminds me a lot about a conversation we had before DNA was chartered. I think Bernard Aboba raised the issue, and we had exactly this discussion, and came to somewhat similar conclusions to Erik. There's no neighbour discovery problem if you send packets from the wrong global address, to another global address. There may be an application problem. And this was not something we were necessarily ging to deal with at the time. We can probably deal with it now, in this document, or another document, if we need to describe whether or not we halt the data heading out using the destination cache, or if we just let the data go out and get retransmitted. That might feed back into what Hannes was talking about some sort of API with indications going up the stack to layer 4 from layer 3. So I don't know if that's additional work that we want to investgate, or if this is a critical issue for this document now. It will be application dependent. Even if you do let it (note: transmission during DNA confirmation) happen. It's the difference between induced loss or induced delay, and there's different classes of applications which treat those differently. JAK: So the current document actually I think the current document actually says, that before DNA you put the addresses in to Optimistic state, which means, and I believe it does say you should wait but I'm not sure, So I guess I don't see any problem with this. I think it really depends on if you think you're going to be in the same subnet often or not. And I don't know that actually, upper layers need to know about it. It seems to me if.... I don't really see that with optimistic DAD you're going to have a problem. Mohan: So by application, you mean that packets are arriving on the old link, which can mean that you can send packets with the global address, but the packets are not going to come to the new link, they'll go to the old link, and that can potentially, cause problems if someone has the same address on the old link. Greg: Not so much about that. It was more about window exhaustion for TCP. What happens to the actual application, if data flow drops of because you're seinding packets which could be used as acknowledgements to continute the TCP flkow stream. You're not going to know they're missing until you start receiving packets, which is at least an additional round-trip. So there are a few problems there. You might get TCP retransmission timeouts. If you're inducing additional delay because you're queueing the packets, it depends on how much longer the DNA process is taking. and whtehr that 10-20ms are going to affect your jitter buffers for voip. so they're the two ends of the spectrrum. Eventually it may be useful to have control over that on a per-stream basis. I don't think we have to go anywhere near that in this document. Sathya: So if I understand the answer to that question, as to what breaks, the answer is: it depends. where you are, what you are doing. So if we take thomas's answer, that if nothing, then no harm done. The answer is not nothing, so, I guess it should be a SHOULD. Greg: My guess though is nothing breaks in Neighbour Discovery. That's my quick summary. Sathya: DOes it affect neighbour discovery? or is the question does it break in general? I'm just reading thomas' question word for word. and his question is what breaks? Since the answer is not nothing, I'm just suggesting that we should probably just go with the requirement that is there. Greg: I'm not sure that TCP breaks. There's a chance of retransmission timeout. TCP has been doing this for a while, and there's some interesting ways to handle packet loss over networks, so particularly over wireless networks. So we could bring up a "Somebody Else's Problem" field and let someone else work on it. Sathya: So you are saying the answer is nothing. Greg: Probably nothing if you send the packets. There may be additional induced delay (note: due to loss and retransmission). Low probability of TCP reset exists. I haven't done experiments, so that comes with a caveat. JinHyeock: Do you even think it's OK to send a neighbour advertisement with SLLAO? Greg: No. JinHyeock: SO I think we could make some distinction. Sathya: What packets you are sending. Greg: Yes, whether or not neighbour discovery matters: It does matter. because Neighbour discovery packets can change neighbour discovery state/neighbour cache state on other devices. So, there has to be a distinction between ND packets, with global addresses and other packets. We'll have to check that. Sathya: yes. Sathya: I just added this 5 minutes ago. So I'll let james describe. It has to do with NetLMM domains, and whether we do eager or lazy switching. 2225. JAK: So the current draft doesn't say much about what the host should do about a defualt router. In the actual case where you have IP links where they are separate subnets, there are a couple of corner cases where this may be useful. If the route rgoes down or if you take it down for maintenance, it might be useful where the mobile node moves from one access point to another. But it's more interesting for NETLMM, where each router has a separate link, with separate routers, and there's a separate multicast domain, broadcast domains rather. The different routers advertise the same prefix, and that prefix is managed by an anchor point further back in the network. So what we'd like to do is have the router advertisments (Note: did he mean router solicitations?) update the mobility anchor further back in the network, and have the same prefix be advertised. The problem on the hosts though is that if it doesn't know it's moved to a separate broadcast domain, and receives an RA from a new router, it doesn't know that the old router isn't reachable any more. It would be nice to have a way for the host, once it receives back a collection of RAs after sending an RS, and the old default router is not on the list, that rather than going through a long complicated process using NUD and all that, it basically says, I know these are reachable, it starts to use these routers instead of the old one which may not be reachable. I was looking at the router preferences RFC today, and it looks like there are (greg suggested I look at this last night) and there might be something we could do with that. But I thinkwe should put some paragraph in the DNA document, indicating what you should do, but it shouldn't be a MUST, because there are some cases you wouldn't want to do this. It's basically an optimization. And what I can do is write some text up, and put it on the list, and if anyone has any violent objection to it, we can write discuss it here or on the list. Sathya: is this an issue only for netlmm or more general? I mean there are ways of fixing this for netlmm JAK: like what? Sathya: We had some discussion on this. JAK: Yeah, but it was a hack. It was for all the routers to have the same link-local address. And that's not acceptable. And it also doesn't work if you have multiple routers on the links. In a single link, you don't need to have the same link-local addresses. Sathya: in a single link, you don't need to have netLMM addresses. But between links, you could have the set of link-local addresses. I don't know what the definition of hack is here, but what the router advertising the same set of addresses. JAK: THis is the definition of a hack: A piece of inelegant design which requires unacceptable amount of human intervention to work (in this particular case). Greg: I enjoy hacks, but apart from that, that solution will not work with CGA, unless they share the secret key. So as far as I'm concerned, that's enough to block that hack. Hacks are alright, but if they stop us doing what we want to do, that's no good. One of the other things that we could consider was that last meeting, we were trying to consider if anyone had any use, in the future or today for non-prefix link identification. An identifier not tied to the prefix, but to the link. Now this may actually be a case that we need it for. I'm not sure. Sathya: No, the link identification, is not the problem here. Greg: You need to be able to tell the link has changed here to identify that the old router isn't available rapidly. Sathya: No, if the link hasn't changed, but the router interfaces have changed. Greg: It has changed in this case. JAK: I think what greg's trying to say is that if you don't have link identifiers which are prefixes, you can have a separate link identifier, which is different on every link, and advertise the same set of prefixes across all the routers. THe way it is currently, the link identifier has to be one of the prefixes. Then you'd recognize that the link had changed and and go through the link change procedure and that will involve getting a separate default router. Now that again brings up the question what about addresses because the addresses are going to be the same. That would require a change in the section about addresses saying that if the prefixes are the same and you've changed link, you don't really have to chenge prefixes. Sathya: Yeah, and we are changing the definition of link, 2832 Mohan: it doesn't work because change of link due to link identifier, according to DNA you have to do all the stuff, whereas what NetLMM wants is just change the default router but don't do the rest of the stuff. it may not exactly match with the link identity. Just say the link id changes, it ,means differne thtings in DNA and netlmm Sathya: We would have to revamp the way link change is handled in DNA. Right now, you have to do , like, if there are link changes, do A,B,C,D. You only want to do D. You don't want A,B,C to occur because that will break everything you're trying to do in NetLMM. JAK: the question is there was some discussion about, Keith moore wanted to be able to do link identification without prefixes. This issue is going to come up if people try to do that because, if they try to do it with the same prefixes like NetLMM it won't work. Sathya: the usefulness of non-prefix linkid is not something anybody has understood. We will need it or not? But we may need it, so we have it open because of that. That's been my opinion always on this. Vidya: So, I don't have an answer to a problem. But let's be sensitive to the the fact that we don't want to do something for NetLMM alone. Let's not write DNA for NetLMM I mean, the whole point of NetLMM is that you don't want to use modified hosts, so I don't think the specs should be breaking that assumption. Hesham: So one thing I don't understand. So what does having a non-prefix linkID have to do with this problem, because I don't understand, first of all the dependency, with the non-prefix linkid and secondly, I don't understand how receiving multiple LinkIDs while you're still on the same link is actually a good thing. I mean you think you're multihomed when that happens. What's the definition of that situation? Sathya: it is not it's greg's suggestion, I'll let greg answer it. Dave thaler: on the topic of where the prefixes are not sufficient to identify the link. NetLMM is not the only case there are cases in mobileip, there are cases in manet and so on, and this is going to be a topic on the INT-AREA agenda this afternoon. So I'd encourage you to come to the last presentation there and participate in that. Greg: That's actually a really good point. One thing we want to make sure of is that we're changing the right part. And that will mena the people who are using these technologies have the same model of a link that we do. So we'll need to check this on list. And we suggest people to subscribe to Int-Area if they haven't already. 3148 Sathya: And james is going to post text on this to the list. Greg: Yes please that would be great. Sathya: This is the last slide, but thomas is here, should we go back through the comments again? We went through the comments before. Should we do it again? Greg: Talk to thomas after. Sathya: Should we recap what is the consensus on each of them? Sathya: (aside) we have time right? Sathya: Thomas, this is for your benefit on this issue of just sending RS, the general feeling is that we should just sned RS, instead of sending NS. Not consensus per se, but the feeling is that we should keep it like this. Again on this one, people don't feel that , we already have describing this situation, it's not complicating the situation that much that we have to go through and rip the text out to ignore this particular problem. In terms of the text for dealing with broken renumbering items. The consensus on this is to change MUST rerun DAD to SHOULD rerun DAD. (Don't know if it is MUST rerun DAD, but if it is we'll change it to should) And give some text explaining situations where we can describe where you don't have to, for example the situation like where probability is less, and things like that. This one is a little bit more open, it depends on the situation, and the application, so there is no, at least I couldn't discern any clear consensus on this, but we're probably going to discuss this on the list. I'm done. Greg: OK this is going to be a short presentation, this is part of the solution space. We have a new neighbour discovery option format. It's in a separate document to the DNA solution. It's in a separate document because it's referenced by two of the documents normatively, and it just describes the new option format for passing (We've renamed it, it people have been calling it TSLLAO Tentative Source Link-Layer address options. We've It's no longer TSLLAO as of draft-ietf-dna-tentative-00.txt, they're just called tentative options. and you just use them when you're a little bit tentative about putting a neighbour cache entry on someone else, alright?) the idea of tentative options is that they work EXACTLY the same way that Source Link-Layer Address options, except that ifa host receives a Tentative Option and it already has a neighbour cache entry with a different mac address, it does not update. it discards the update. In that case it acts as if no option exists in the solicitation or advertisment, and the document also specifies which packets you can send the tentative options in which are compatible with 2461 neighbour discovery. Which means that these options are invisible to 2461 compliant hosts and they do the same operations that are correct for 2461 Neighbour Discovery, and they give added value to those that can read and understand them. That's the principle thrust of the document. There's another ouple of sections about trying to send back responses even without Neighbour cache entries. So, it's very short, like 10 pages or less, please read and review it. We need reviews on this. If we get a couple of good reviews, it's probably OK to send to WG last call. Thomas Narten: I have one question, I did a quick review of it last night, and at one level it seems like a fine document, the question I have is up until now, with optimistic DAD, we've taken the position that "do no harm" or do nothing that changes the status of the network until we're really sure. This document takes a step across that line. I think that in particular, if A and B want to communicate, if B has no information about A, and if A sends a Neighbour Solicitation with a tentative option in it, And if B has nothing in its Neighbour Discovery cache, B says let me add A. And my understanding of this is that the Neighbour Cache entry looks exactly the same as the normal one created by neighbour discovery Greg: Yes. Thomas: And this presumably creates new failure or incorrect operation scenarios that we've so far avoided doing. Greg: Yes, so this is for a node without any existing neoghbour cache state, not even an incomplete entry for a particular node, and so the device doesn't have an ongoing session with someone. Now you've got a quiet node on the network which actually owns an address, and you come in and you're optimistic and start sending these options to the router for example, and it creates existing neighbour cache state on the router, which points to the new node. Now the thing is, you will then do neighbour discovery/Duplicate Address Detection for that optimistic node. Thomas: What do you mean you will? Greg: The optimistic Node will do Duplucate Address Detection, and then the defending quiet node will send a defending Neighbour Advertisement to All-Nodes' which will update all the existing neighbour cache entries and override. Thomas: So you're relying on the Duplicate Address Detection to be run in parallel, so the incorrect state will be flushed very quickly. Greg: It will get flushed very very quickly, except the thing is I know that's not guaranteed, but there was no existing neighbour cache state, for that device. Thomas: that makes me feel better, in that it significantly lowers the window of incorrectness, if there is one, but it does rely on neighbour advertisements being Multicast Greg: Yes. Indeed, which happens very rarely, and they are for Duplicate Address Detection only: ff02::1. Thomas: I'll have to think about that a bit more. Greg: Is it worth discussing in the document. Thomas: I think definitely, as in one sense, here is the danger of this approach, but here is why this is acceptable dnager, given this, that and the other. And in particular if it has implications for what is going on in parallel, and if theyhave to be tied together. There's also a tendency to take shortcuts in that area, for other reasons. So if they decide they need to take a shortcut in that area, they know it has implications somewhere else. Greg: I agree with you, we should be very explicit about this. I think previously, it was a hack, and if we're going to be clever about our hacks, we have to be very very explicit. Thomas: I guess at a high level, I guess what I'm (I don't want to say that I'm worried or concerned) but something I do worry about at another level is that we can make DNA and Neighbour Discovery so precise, that what we expect of the behaviour of all of the nodes that to a certain extent we're fooling ourselves in that implementations actually do these thing correctly in all cases. And that it may be safer to err on the side of simplicity, rather than push the envelope and hope that people do all the right things in all the right spaces, and what are we solving here? we're trying to solve a round trip? Greg: and the possible loss of a multicast packet. Thomas: So the important question is: how important is it for us to actually have this optimization in the first place? Greg: So, MAY include this option? May take the document and throw it in the bin? Thomas: Well I'd not be in favour of this option being a MAY implement so much as a here's what we think everybody ought to do, or it's not really worthwhile and we don't want to do it at all. As Opposed to a MAY, where you run into the situation where you don't really know if people will implement it any more, and you have to deal with the whole spectrum of possibilities. Which makes it even less predictable even. Greg: So we need to make sure that Weve probably got two discussions, We need to make clear what the failure and recovery cases are. Thomas: Yes. Greg: We need to make sure that devices, at least, discuss on the list, and it may be easier just to try and craft text, I'm not sure. But to describe what ranges of behaviours are likely and describe what the issues are for those behaviours. Thomas: So let me ask another question: Which probably shows my age or something, but in the current 2461 world, if a node sends out a neighbour solicitation without a Source Link-layer address option, where does the neighbour advertisement go to? Greg: you can only send out a Neighbour Solicitation without an SLLAO if it is unicast. Because a multicast MUST contain a Source Link-Layer Address option. So it's a bit annoying, but the Router Solicitation is only a SHOULD send the SLLAO. Thomas: what I'm trying to understand is that suppose this became a document and were implemented, what do existing implementations do, and if another node did this tentative option, optimistic DAD and then the DAD, would the default behaviour actually be what we want or would we already in practice have a gap where neighbour advertisements are not sent out multicast. In which case the assumption that the problem is self correcting is actually not a valid assumption. Greg: OK, the neighbour solicitation neighbour advertisement isn't really the big issue here. It's the router solicitation/advertisement that we actually... Thomas: It's the router's cache you want to update Greg: The Router Solicitation is the only one we can effectively do anything with, Thomas: because of the option rules, OK. Greg: The router solicitation allows us to do this and we don't have to have a fixed destination for the router solicitation, and we may have changed links. it's not actually a lot of value, to send a neighbour solicitation. If we're on the same link, we can send the Source Link-Layer Address option, which means we could have sent it multicast any way, so it's only really useful if we're changing links. Now it doesn't hurt if we're on the same link, and the neighbour cache entry is the same right, we just send it with the tentative option instead of the source link-layer option. So if we artrive on the new link, and there's no support from the router, there is some question still, whether or not the router will multicast because it doesn't have an existing NCE or it will do neighbour resolution. Now I've seen Linux Boxes do neighbour resolution, in fact, I think that RADVD doesn't do any update of the neighbour cache entry when it receives a router solicitation, even with a source link-layer address option. (except in my hacky implementation). So I've tested this. there are some limitations to the implementation. There are limitations to how existing implementations do this. It would be good thing I guess, to get a summary of this out on the list. Thomas: I think it would be good to understand the target environment where this should work, and whether or not it have the desired impact in all cases. And go from there once we understand all the issues better. Mohan: Not to repeat what thomas said but initially this was meant for router solicitation, and then it was extended for neighbour solicitation right? So for router solicitation, case it can be limited to one packet, so it can be done without a neighbour cache entry? Since that was the original case I guess. If it was only for that case then you wouldn't need a neighbour cache entry. Greg: There's a value in keeping neighbour cache entries, in that it gives you an idea of who have been sending router solicitations. If there are anonymous mechansisms, if there's not state retained, then you can't do rate limiting for example. If you have devices come along, and they are getting sent unicast RAs with no neighbour cache state then there is a potential problem Mohan: But does the DNA spec have anything today,There are like 3 RAs, there's no other rate limiting is there Greg: There's not a lot of rate limiting: there's a token bucket on unicast RAs. Greg: Anyway, that's a little bit esoteric, really we can discuss that on list. Mohan: ...if we feel that there's a danger of creating a neighbour cache entry, that can still be limited as... Greg: We'll discuss that in-depth on list. We'll definitely make it two threads I think. Jinmei: May I make a question for clarification? With this mechanism, an optimistic Node sends a unsolicited Neighbour advertisement with this option? Greg: No, because that won't work. Node don't always accept unsolicited neighbour advertisements, there's a good reason for that, but what happens is that because neighbour resolution has to work, they always accept the neighbour cache state change from a solicitation, which may not be a good thing in general, but it's required to work, so if you send a router solicitation or a neighbour solicitation with a source Link-layer address option, it will create a STALE neighbour cache entry. Jinmei: So this option is for solicitations? Greg: This is primarily for solicitations. And if its a Router Solicitation that's typically the way you'd use it. Jinmei: and if the scenrio where the address is actually a duplicate, the defending node will eventually send a neighbour advertisement to All-Nodes' multicast address with the correct link-layer address, with the override flag set to one. Is this the assumption? Greg: Yes, I mean that the assumption is that DAD defence occurs. and I guess that means, all nodes receive the neighbour cache update. Now because it's an unsolicited NA, only those nodes with an existing neighbour cache entry will update their cache, and if they receive the NA should update the incorrect cache entry. OK? So we'll take those two issues to the list, and see if we can gravitate towards text ior adecision, based on what we've been discussing. Suresh: Last session this draft was presented, about how fmip works with DNA, and got the sense of the room that people were really interested in this work. And after that, the conversation degenerated, and people were talking about the FMIP Proposed standard coming out, and that it should include that. And then some people said like OK, we don't want big documents, we want documents linked together, and it broke down into a discussion of should we have html RFCs with hyperlinks and stuff like that. So we can finally get a feel fo the room as to whether we want to do this in DNA as a separate document. So, it was adopted as a WG document, I think there was clear enough consensus to adopt it as a WG document, but we want to know how to proceed on this. So if you have any feelings about this now is the time to speak about it. Hesham: I don't have any feelings, I have thoughts about this. Greg: That will be a change :) Hesham: so given the fact that FMIP is being update for PS, and given how small the amount of work to get DNA and FMIP to work together. I mean the new version of FMIP will have optimistic DAD anyway, so I think it makes a lot of sense to have it in FMIP. It's an integral part of FMIP to detect these changes quickly, and whether the the work is done here and because the work is being done here, for completeness the RFC's being updated anyway, I can't see a reason why not. We don't need multiple documents which update or complement each other. Rajeev: I think in principle I agree. but it's probably better to have a standalone document which specifies the interaction between two protocols. I mean that way we may have to put everything else in FMIP about how it interacts with some other protocol. I prefer just documenting these two pages, which it is, today as a separate document I don't think there will be a lot of changes for FMIP PS, I mean FNA may be made optional. otherwise I think Optimistic DAD per se, this document describes about it, saying how you would work with an optimistic address. So I would actually prefer leaving it as a standalone document, just to avoid any other protocol coming in saying how to work with FMIPv6. Either we could put it in an annex or an Appendix in FMIPv6, saying for clarity, or we presented it here, just present it as an informational anyway. Hesham: Can I ask? what do you want in this document you wouldn't want in FMIPv6? What would you describe in this document that you should not be described in FMIPv6? Rajeev: its set of messages, how you would do FMIPv6 with DNA. So I think FMIPv6 should describe FMIPv6 messages, not how it works with another protocol. Hesham: We do that ll the time for example, with security. We don't write a separate document describing how to use it with IPSec? Greg: Is every Mobility related document going to have a DNA considerations section? Rajeev: That's my concern. FMIPv6 should just talk about FMIPv6 protocol design rather than how it works with other protocols. JAK: I have a little bit different perspective. Because of thetotally antiquated, documentation technology which we are forced to use in the IETF, we don't have hyperlinks, ??: You should bring it up at the plenary JAK: I did and I was told to go write a draft on it. This basically makes it impossible if you're an implementor to really know in a lot of cases, without doing a full text search through the IETF archives and correlating things. So we came to this, I was involved in two design teams in different working groups, and we came to the conclusion that where we could do mix and match pieces or put it in the one draft, we should put it in the one draft, because of this problem therefore I feel that we should have one draft with describes FMIP and where it touches things like security. I mean security there are already documents outside, becasue there are different ways to do it, but DNA and optimistic DAD are pretty central to the way FMIP works. So I think it should be in there. Jari Arkko: I'm the incoming Internt Area Director. And it looks like I will be having this group. We had a discussion with Mark yesterday on which groups we'll have and I got this one. Greg: Thanks for your enthusiasm :) Jari: Its' kind of a new thing for me. I haven't followed this discussion previously, but the question I had was: is this in your charter? Do you think it falls under the ...? Greg: We origianlly had intended to have a BCP document, which was in the charter, and as part of that, the original document, we had an appendix which wasn't developed for a long time. It was Appendix A: FMIP with DNA, and then nothing. So we thought it was in the charter, as far as that went. Well we thought the BCP document was in the charter, and defining how DNA interacted with existing protocols was probably in the remit of the BCP. So whether it's in the charter or not now, has a lot to do with what the AD thinks. (inaudible speaker) Greg: Essentially the BCP was in the charter. Defining the interaction with existing protocols particularly neighbour discovery but also maybe in this case. Thomas (quiet): You shouldn't say was, say is. Greg: There are more tenses in Finnish anyway. Jari: we'll have to take a closer look at this. Greg: It's the uncertain look in your eyes which is why I'm saying was. Jari: OK. The other question I have is that you have a lot of documents. Do you think it's OK to take on new ones at this time, or should you complete the other ones first? Greg: we're not necessarily opening up new work though. This was something that was planned from the start, so whether or not it's part of an existing document, and whether that document is in mipshop or, whether it's here. the work has some interest, I don't know if this is the right time or venue or not. So that's something we can readily discuss. Jari: It think the management of where this is and whether it falls under the charter needs some further discussion, I'm not personally ready to make that decision now. Greg: Previously people weren't discussing PS FMIP and we wanted to make sure this didn't fall through the cracks. Thomas:I just wanted to say something based on my former AD hat, and it's about a year ago now, So when we chartered thsi group my belief and my intention was that DNA should be kind of upper layer agnostic, because it's about to be about how IP hosts operate generically, whenever we start to talk about FMIP FMAP or FMAR, or whatever, I get a little concerned about all of these different ways things are done with DNA because the it's supposed to be done once in one place in the stack and everyone just benefits transparently. Greg: Yes, that's I think we'd like. Rajeev: so a quick response to that is, there's no change of protocol in any way here, we don't specify changes to DNA or FMIP in any way, we just specify the way the protocols work together. Thomas: My response to that is, on one level, if it doesn't change the protcol why is it needed. And if the document is needed because the specification isn't clear about what you're supposed to do, then the true nature of the protocol isn't just the on-the wire formats, it's the behaviours that all the implementations have to do. If that needs to be specified because it's not clear enough... Hesham: Another thing is who are the beneficiaries of this document? if it's someone who's going to implement FMIP, and wants to use the DNA service, then wouldn't that be in somewhere the people in FMIP are going to read? Rajeev: That's my concern, I mean how many other protocols are we going to define in their interaction with FMIP. For security purposes we already have a different document. How you set up security, So we did this because Originally we thought... Hesham: But that's being don in the same working group. Greg: Can we please start putting FIFO back in the queue? Rajeev: I have maybe a couple of comments Greg: You're at the front of the queue. Rajeev: So I think that the context is that we thought we should specify it, and that people will keep coming back, it should be documented somewhere. Whether it's in the charter etc, we started with this BCP, and I don't know whether we need to go back and change that bit, or whether mipshop should take it, well mipshop already has a lot of documents too, it has a pretty full charter. So I don't care. We started here because we wanted to document this, and it's a couple of pages, and it's an informational document. Greg: Don't go away rajeev, I've got a question. Vidya: So I apologize that I'm making this statement without reading the document in a long long time. I sort of share thomas's concern here. We don't write a document on how a protocol works with neighbour discovery. And... Greg: Well, recently we have... Vidya: Well, bottom line is that we don't have neighbour discovery considerations sections, and I see DNA as speeding up Neighbour Dsicovery for mobility and handover, and It's kind of disturbing to see that you have to come up with a document which describes how you work with FMIP, HMIP etc, because aren't you then defeating the purpose of DNA? Greg: I guess that there's an essential difference with FMIP. The difference is that FMIP starts before DNA starts. The prediction capability starts before you arrive on a link. There's a mismatch there, an existing mismatch. whether we think we should document that, as part of theFMIP process or part of the DNA process is another matter. Vidya: A quick point on that, james brought up the issue of concerns in the past where you have several documents where things are captured. I was one of the people who complained on the MIP6 mailing list that we shouldn't have 10 documents describing about the same topic. However I'm opposed to having an RFC which is like 120 pages long. And if we start putting all the protocol elements and interactions in the FMIPv6 RFC, it will happen. Which is also undesirable. So from that point of view I do accept that we could keep this as a separate document. Greg: So the question I have for Rajeev and for the others is: is there any problem with us keeping this as a working group document, it's not going to require a lot of time and care and attention, and the other question is, if we keep it, do we have any urgent need to publish as an RFC? Rajeev: One q at a time? Greg: Do we have any urgent need to publish the document as an RFC if we're not going to lose state? if we're not going to lose the information in the document? Thomas: Can you better define what you mean by urgent need? Greg: Is anyone using FMIPv6 with DNA or is anyone likely to implement in the next 6 months? Rajeev: We don't know that here though? Greg: well anyone here going to implement FMIPv6 w/ DNA and they're willing to say it in the room? Thomas: I'm not really sure that's the right question, I think the previous speakers made a good point, which I wholeheartedly support, about a balance between lots of little documents and a huge behemoth document. But I think it's dangerous to try to make a hard and fast rule about this. What I heard about this document, the one we're talking about is that it's two pages long. That strikes me as a fine thing to put in the base FMIPv6 spec, if it's only two pages long, and we shouldn't really need to debate about it. Clearly this group should review that particular two pages, and maybe it's easier if it's a separate draft and can be put in an appendix later, but at the end of the day, we have to focus on what the specification implementor needs, and having fewer documents is often better than having something that is scattershot. Greg: I was trying to figure out. And maybe I left this unsaid. I cannot say what mipshop will do with the document, I'm not offering to put it in MIPSHOP because I haven't discussed it with the mipshop chairs\ but I think we can hold on to it for the moment, and try to get something done with it. Does anyone mind if we hold onto the document, and try to get mipshop to adopt it? Thomas: I guess I don't know what you mean by hold onto it? I mean are we in danger of ejecting it and sending a note to the ID editor? Greg: Yeah, strike its name, this is anathema... No, we're not going to say that but, I mean we have to put alittle bit of effort into maintaining the document, it has to keep on getting regenerated if something happens to it, you know. Jari: I 'm not sure it makes a lot of sense to put a little bit of effort into something, or to keep a draft around, either we have in interest in doing something or we don't. Greg: OK. Question is, do we go for an RFC in this group? I think there've been enough opinions discussed, maybe we can ask for one or two opinions more, and then we can ask for a consensus call because it's pretty clear people have some good strong opinions on this. Rajeev: I'm the editor of the document. I want to keep the focus of the document on revision of the FMIPv6 specification there, OK. I think of this as something which people who are using FMIPv6 with DNA may find useful. FMIPv6 can work without DNA. So I don't see why people want to put this as an additional item in the draft revision process. That we are taking there. I think that for pure clarity, I think it should be here. And DNA is another protocol which is being worked on, so I hesitate to put it in an FMIPv6 document, which should be focuessed on resolving the issues, we're getting from implementation experience, and things like that and keep that focus. Alper: Will be the possible RFC informational? Greg: yes, informational. Vidya: Given that this particular thing is 2 pages, I can be sympathetic to it being in the draft, however as Rajeev pointed out, DNA is an option, optional thing for FMIP. it doesn't depend on DNA to work. I know there are a lot of should and mays and there are a lot of optional things in the draft, but personally, if we consider adding two pages. If we end up adding 2 pages about everything. Greg: please be aware DNA is optional for FMIP if you have perfect information about the network you will be visiting. Now I don't know much about Perfection? Vidya: Are we mandating DNA for FMIP? Greg: are we mandating DNA for Access networks? Vidya: If we mandate it, it should be in the fmip spec. Hesham: It's hard to say what should be mandatory in an optimization. FMIPv6 can work without DNA , but because it's an optimization, how well would it work? It's not an on/off switch. there's a spectrum of ways about how, things will work. It's not a good way to describe how it will work or not because there are lots of variations, some [people depending on the deployment scenario, the type of access that you have, different things are optional and different things are necessary. Rajeev: This mandatory thing is debatable, because DNA may not be available in the access network, you need to know what you should do if everything fails. Greg: There will still be CPL. You can work DNA with unmodified routers, theres a specification, Rajeev: that we can state, but what I'm saying is that if information is not available when you move you don't get the performance benefits, right? Right now I don't have to mandate anything, you just fall back to mobile IPv6. I hesitate to say you should use DNA, when it is available, but I cannot say you must use DNA... So that's why I think there's a clear separation here. That's why I think we need a separate document. Greg: Any more comments? So do you think we can make a consensus call on this? Rajeev: Just to go back on the minutes of the last meeting. there were two references on hyperlinks and whether this can be part of FMIPv6, in the last meeting there were two. But, there was consensus. Greg: I think that suresh had a listen to the audio, and perhaps there was something missing from the audio... Rajeev: But if you look at the text notes you can see there. Suresh: there was consensus, but then the discussion degenerated after, so that is why we want to get the real sense again because there was consensus before all the facts were on the table. There were some people who had different opinions and didn't express them before the consensus was called for. and then they came to the mike, so. that's why we want to get the sense of the room again. Rajeev: when you ask the question, you can't be sure you know all the facts into the future. Greg: We've got excellent rear vision. Thomas: make a proposal on what you want to ask us and the other observation I'll make here is that we're spending an awful lot of time on precess here (which is a shame) instead of moving on and doing what's right. Greg: OK: Can everyone see that? Thomas: Is that the only question you're planning on asking? Cause I'm not sure this is really the right set of choices. (Should we work on DNA/FMIP in this working group) Greg: No, lets' see what mipshop can do? I don't think we should drop the document. Someone has to handle it. Thomas: I think there's agreement on that. you can do a quick question: Should this document just be tossed out the window? Or should the work get done somewhere? Suresh: No, but there was clear consensus on this document should be worked on. Thomas: I agree Suresh: So that question is out of the way, I don't want to call it again, because that was very clear, but the only thing which is unclear is if it should be a separate document here or it should be folded into the FMIP spec. Thomas: And the way you've written the question is not very clear on that, I mean the way I would phrase it is: should we ask mipshop if they will take this on in their documents, or should we take it on ourselves, or something like that. It kind of depends on what they're willing to do? it's not like they're going to say: we're not going to touch this one, it's your job. Greg: well they might... Thomas: we can evaluate it. Rajeev: We can't say MIPSHOP should take it on here. Somewhere else is like waving hands... We agree that this is something of relevance to DNA. Thomas: Should it be here? My personal view is that this group should review the text, but I think the text itself should end up in the appropriate mipshop document or not? Question: Should FMIPv6/DNA be published from here or in a MIPSHOP document? Greg: Here are our two options. this is to get the feel of the opinion of the room (sense of the room). Should it be a mipshop document or a DNA document? So people really think it's a mipshop responsibility. is this correct? Would you like us to talk to the mipshop chairs? We'll discuss this offline with the mipshop chairs. and probably the new AD. And we'll find a destination for this. If it's not mipshop, we'll talk to the AD. Rajeev: So, You have to ask the MIPSHOP group to figure out? Greg: Yes. Rajeev: I'm still confused. Greg: We're not dropping the document in the mean time. Rajeev: put it somewhere, but I hesitate to put it in FMIPv6, there are other things to do in FMIPv6 than take this up, and DNA protocol is still something that's being worked on Greg: Yes. I guess we're not suggesting that this is rolled straight into the FMIP document today. If it makes sense at some time to merge them, that's not ncessarily the DNA group's choice. We'd ask if they could keep and look to publish this, Thomas: you seem to be implying that there's not enough bandwidth to take this on in MIPSHOP, but I also hear it's kind of important to the base document. This should be driven by the community that needs it. which I believe is FMIP Rajeev: I don't know if the community that needs it is FMIP. per se. it's both. If they implement DNA and are interested in using Fast Handoffs. Thomas: If they're interested in Fast Handoffs, they are FMIP community by definition. Rajeev: I don't know if I can say draw a clean line and say those who want FMIP just do this, those who do DNA just do that. I think it's the interaction, which makes it interesting. FMIP can make use of DNA when it's available. Greg: But not vice versa, so it's not necessarily something which is going to feed into the core of DNA ever, so maybe this is the right way to look at it. Let's see whether we can get it worked on in MIPSHOP. Hesham: DNA is the base, and anything else uses DNA. So the users of FMIP are the users of DNA. Greg: We're very simple here. only the basic stuff. Greg: So is that OK? We'll go ahead with that. Suresh and I will try and talk to Gabriel and Stefano. 7836 Suresh: We're kind of behind on the milestones, like 1.5-2 years. So this is the timeline we came up with. So they're kind of realistic, so take a look at it. Greg: If we get acceptance of the MIPSHOP chairs, we'll give FMIPv6 DNA to them that will disappear. As described before, we'll try to work out the interaction between DNA hosts and Complete Prefix Lists, whether they are essentially the same document or two separate documents, they may merge as a milestone or may go ahead separately, depending on the WG. 7923 sathya: I'm the editor of DNA hosts. I don't know if june 2006 is going to happen. I don't know if I can just do changes (can't do that right), I've been waiting for people to give me some pointers, on that, there isn't really anything happening on that. And now we have this idea of whether we want to merge it with CPL or not (and not enough traction on that either). Suresh: with regard to reviews, there were people who committed to doing those reviews, I guess they were just caught up, so maybe I'll just prod them. I will ask more people to do more reviews, but the merge thing could put a spanner in the works. So we don't know yet, but this is, kind of what we are thinking, but could be wrong. That's why it says possible milestones. Sathya: June 2006, I don't think DNA hosts is likely to, if it merges and something comes out of it before june that's one thing, right, but if CPL is going to be separate and goes in June 2006, I think CPL is in pretty good shape... But hosts is not in the same shape to go at the same time. John Loughney: I was going to comment on a process issue, this seems like a lot of WGLCs running at the same time. And I'd be worried you can't get the reviews for all of them. They probably should be staggered a bit more. Greg: thanks Thomas: Sorry about being late to the meeting, and all, but what I wanted to find out was what was going to happen with all the documents, and how to merge them we can do that offline, one fix in a sense is that i would really like to see Routers BCP and Complete Prefix Lists document merged, because at the end of the day, what is it that the implementer wants. They want A document for hosts, that's got everything in there and one document for routers. Everything else is a distraction and will add confusion Greg: Actually i think I'd look at it the other way around, I'd think that hosts modifies the hosts behaviour merged in with CPL which is working with unmodified hosts. Thomas: One recation, to a comment that was made earlier, my personal opinion is that DNA is an extension to Neighbour Discovery. We want everyone to implement it. We can't mandate it, in a must sense, we can certainly make it a SHOULD, and hopefully if we make the protcols right, it should be easy to implement and makes sense, it will happen over time, and so we don't want a bunch of documents you're only going to care about this you're only going to care about that, you have choices, because at the end of the day, what we're asking to implement is not that complicated, in some sense. So just specify, here's what hosts do, here's and it might be broken up organizationally, because it's convenient, in here's how you deal with an unmodified router and here's how you handle a modified router. Except that doesn't the host do the same thing in both cases? In that case, do it once, and if you get a response in the case the router doesn't understand this, this is how you react, if the router does implement this here's how you react. But keep it concise, and here's what we want all hosts to implement. And the same goes for routers, here's what you want all routers to implement. Greg: Just to clarify, Does that mean essentially the ideal is that we have a We have the protocol modification? broken into just hosts and routers? Thomas: I'd be fine at a certain level with a single document but organizationally it makes sense to talk about the router behaviour and the host behaviour because from the implementation perspective, you have two groups of players implementing. two documents is a fairly clean split and the other is sections in the same document. Greg: I'll agree with you, that's how I implemented it. I did the routers first and then I did the hosts. So it's not particularly onerous to describe it like that, even including.. Thomas: Right, part of the problem I didn't pay attention to DNA for a while, is you have a lot of documents. and it's easy to take on more work, but it's not in the WG's best interest to keep on taking on more documents with overlapping text, and repetitive text. Even talking about here, if I look at the list of documents, we have a bunch of them which I don't understand their purpose given that youu just want to know what you need to implement from the host perspective. All the other stuff is a distraction. Either you need to implement it or not. I've seen plenty of cases where you put something in an obscure RFC and it gets missed. And that's very unfortunate, so in some sense, I would like this DNA stuff get folded up into neighbour discovery, and it's in a separate document because it was developed later. Greg: I guess that's a similar situation to what happened with SAA (2462) and ND( 2461) 2462 is just he hosts' component right? Essentially it's how the host interprets what's on the network. That's what stateless address autoconfiguration is. Thomas: Well, the history is more complicated, because there were two documents originally. You could argue it that way, and combine them all in the same document, and try splitting them that way. i believe that the structure of the documents is that it's broken into the routers part and the hosts part. I would really like to push the WG in the direction of, if at all possible, just have two documents, and put the essential stuff in there. Don't put so much should and may, and they'll do it. Or they won't. Dave Thaler: So I'd agree with thomas. It seems you have a huge bunch of documents at about the same stage of progress so it doesn't seem like any reason in terms of mismatch regarding when they're going to be ready to go to not try to combine them. So I would strongly like to echo that two documents would be good. One would be OK, I personally prefer two because It's easy to point people at one document, to say this is what I implement, rather than trying to describe things at a finer granularity, like for example with the node requirements. There's the host part of this and the router part of that, so it's technically, correct to do that, but it's not very convenient. So two documents, and you say here's the RFC implement that, oh router guy here's the RFC implement everything that's in there. So I would like to compress as much stuff as possible into two documents, but preferably not into one. (inaudible) Exactly, So they're checkboxes and when people come up to the checkbox list they don't go to the correct granularity, they don't say when you implement MLD you have two check boxes for the router side versus the hosts side. they say do you support 3810? And you just have one checkbox there. And so for getting people to do the right thing there, with implementations and compliance things, its helpful to have one RFC per requirements set. Erik: So we talked about this stuff earlier, but I guess thomas wasn't here then, I think that splitting it into the hosts/router one doesn't make any sense, because if I did that to neighbour discovery, the thing would be a mess. Because you'd have to decide where to put the packet formats. If you're going to describe and you also have to figure out how are the people going to read the document so that they can understand it, you're going to need some high level explanations of what typically happens as part of the introduction, before you get into the details of the protocol. So if you're talking about a protocol where two parties implement different pieces of it, Having the two piece actually be in the same document makes a lot of sense. Because that way it goes with the packet formats as well. So the comments I made earlier was that yes I think we should write the documents with the implementor in mind. It's not clear to me whether that means it's optimal to have one document that covers all the pieces. I do care about whether one can in a sensible way, with consistency between documents, have multiple documents that specify the different pieces, right? What I care as implementors is actually not having to read between the lines, and deal with inconsistencies between documents, because I expect the implementors to want to implement something, like a host implementor, wanting to deal both with the case, when the routers are not modified and the routers are modified. Today our chair postulated that he could figure it out, but just reading the documents, it might be hard, right? I'm not sure how many documents it needs to be, it may make sense to do a high-level view of what would actually the flow be, and think about it as here's the order that one would read things, in terms of sections and then come to maybe this piece is standalone enough that we could have it be a separate document we could refer to. Or perhaps not, because if it becomes a 200 page document, it becomes hard to get people to review even pieces of it. Greg: I know what you mean. I've been reading 80 page documents recently, and it's quite hard in some cases. Erik: It's easy to have a thirty page document, making a detailed review of the pieces, and have someone lese look at how do the pieces fit together right? Greg: we actually had a document in the charter the solution framework. which was supposed to be a high level overview of what you need to do. That we got distracted by looking at all the details for a while. I think that's what happened. It's lapsed. Erik: but I also don't know if that's the right model in terms of carving things up. Maybe sitting down and doing the high level here's the set of thiongs we need to implement on a host or on a router. Now are there pieces which make sense to be standalone. Because having a 5 page introduction that doesn't say much but refers to a bunch of other documents, might not be sort of helpful, right? Maybe there has to be a bit more meat. Greg: I get the feeling that we're not ready to redo the charter discsussion completely, I think we need to do some charter discussion on-list and see if we have a feasible way forward. I don't think anyone's arguing we avoid doing this for implementors. Everyone's got the same idea. So let's see what we can do to get the basic form of what we need to give the implementors. I think that's the straightforward thing to do. And let's do that on the list in March (Note !) The first cut, w'eve got to start the discussion sometime, right. Please approach me or any other likely suspects about this. We'll natter on, and get some things on list soon. I don't see any other way forward than to take this to the list. Does anyone else have an opinion? Previously we've had very small groups of people actively involved, and not necessarily discussing things on list this is critical for the function of the working group, this has to be done on-list. If there's anything you can't say on-list, then consider not saying it. So what we'll do is discuss this on-list as much as possible and get everyone involved. If you've got an opinion, please say something. Sathya: I just wanted to say. the routers BCP, isn't targeted at implementers, there was a discussion on this in washington I think. And that's why we split that off. So I think the routers BCP stays separate, Greg: as an administrative thing. Sathya: and so two documents for routers and hosts, doesn't... Greg: It's what prefixes and what timers, that you can set using existing neighbour discovery to make DNA more efficient. Sathya: The router BCP does stay. Leaving one other document for the routers and for the hosts would ideally be great but, I don't know, the solution document has both routers and hosts in it. But if you look at DNA hosts and CPL, it's targeted towards unmodified routers, so the solution document like erik mentioned about neighbour discovery, has both router behaviour and host behaviour for modifyin everything. hosts and CPL are for unmodified everything.. Greg: we might have to completely discard the idea of the existing documents that we have, and just figure out what we want. And the reason why we've got the documents today is historical based on how things developed. We've essentially got enough knowledge now to decide what we want and just do it. That might mean that text isn't shared between the documents. It might mean we just read the documents we write the text which we need, right, and we do a good job of editing them. I think that's reasonable don't you? Sathya: I don't know if you want to start from scratch? greg: we're not necesarily starting from scratch, there's just no guaranteed path for text to move out of one document and into another. Sathya:I don't mind for the host, but the solutions document. Greg: yes, I understand there was a design team, and what i'm trying to say is that if we're convinced a certain piece of text is necessary, it goes into the document. And the structure may be correct in the hosts, may be correct in the protocol, but let's just work out what structure we need. Thomas Narten here: I came up here originally to echo Erik's comment that where the packet formats go is a problem, But I think it's important to have a high level overview is really good, and I actually wrote a bunch of text and wrote it on list, and I would be very happy to continue to expand on it because it's very useful for someone to be able to read all that and understand at a higher level what is going on, and how things are supposed to work. Greg: I think that Erik and JinHyeock did a job before of initially outlining which documents things were in, but also, placing a description of what's supposed to happen. The solution framework document. It might be good to talk to those guys about it. Mohan: So you tlaked about the solution document splitting it into two. I think that may be quite difficult, right, because last time when I read it I had to go back to the previous section, it's very difficult to read just one piece. greg: Is that a problem with the document or the ... Mohan: it's just very diffcult to. When you ay the hosts' behaviour, I would like to know how the text was written for the routers. it's part of the review, I'm not sure. So keeping that as two separate documents, makes little sense to me, I don't know. Suresh: we have not decided on two documents, that's still open to discussion. Erik: one other comment on DNA routers. Maybe we should rename that one because it's really about operational considerations. Greg: for networks supporting DNA. Erik: Yeah. And calling it routers makes people think it's something you implement in a router. 9407 Greg: networks, OP networks or something. Sathya: I just want ot agree with mohan on this, the solution part splitting it into routers and hosts won't work. Erik made a comment like, neighbour discovery being unreadable with the packet formats. It is the unmodified routers portion of this which is a mess now, and we don't know how, to some extent I'm in favour of merging them, but I'm open to other reasons why we should not. (inaudible) talking abouthosts and CPL. Greg: Let's just figure out what we need to tell people and figure out the top level of what we need to tell people, figure out the ways we want to split it, There'll be a couple of different ways, and then we'll split it. and then we'll see which documents fall where. So if we can forget about the documents, and know we've got enough knowledge and text to start putting in the final document, whetever it is, I think that we'll make some progress. Any other comments? Thanks very much, We'll see you in Montreal.