Mobile Ad hoc Networks (MANET) Minutes Meeting : IETF 89 Wednesday March 5, 2014 Time : 0900-1130 Morning Session I Location : Palace C Chairs : Joseph Macker (absent) Stan Ratliff Secretary : Ulrich Herberg (co-chairing the session with Stan) Jabber : http://www.ietf.org/jabber/logs/manet/2014-03-05.txt Audio archive: http://www.ietf.org/audio/ietf89/ietf89-palacec-20140305-0900-am1.mp3 URLs : http://www.ietf.org/html.charters/manet-charter.html http://tools.ietf.org/wg/manet/ ========================================================= o Bash the Agenda: Ratliff Stan Ratliff (SR): Welcome to MANET. Lets look over the agenda. Consider the note well. If you are at this meeting you are operating under this notewell. Step to the mic say your name speak clearly. There are people listening on the jabber so we need to take care to give them time to keep pace. Stan: So the agenda. Standard bashing the agenda. (Provides vocal overview of the Agenda) This last one is about steps forward if I'm right? Thomas Clausen (TC): No, it has more to do with work we have done that is not specifically MANET but may be MANET related. Stan: Last is the open mic slot, it will be the first to go if we do not have enough time. Stan: Agenda approved. o WG Status/Overview: Herberg Ulrich Herberg (UH): Document status talking about 2 drafts draft-ietf-manet-olsrv2-rmpr-optimization and draft-ietf-manet-nhdp-olsrv2-tlv-extension have been approved, which is great. UH: We also have a MIB document in IESG evaluation (draft-ietf-manet-smf-mib). Bob is not here today, but he has been working on this. Thomas: There has been a lot of education going on with the MIB doctors and it hasn't just been change, but more education. UH: The IESG says that we should use netconf and yang for writable management modules: http://www.ietf.org/iesg/statement/writable-mib-module.html Thomas: Would we need a DLEP yang/MIB module? Stewart Bryant: My understanding is that their position is not to specify something that no one will implement Thomas: So my question is anyone going to implement DLEP and wants a MIB module? Roland Schwarz: We will start to implement DLEP in a couple of weeks Teco Boot: I think it makes more sense for the router to have a MIB module for metric access UH: draft-ietf-manet-report-mib is expired, but needs to be renewed UH: We have 3 active WG drafts o draft-ietf-manet-nhdp-olsrv2-tlv-extension: Dearlove/Clausen draft-ietf-manet-olsrv2-rmpr-optimization Thomas: There is a sense to all of this. The adventure started 2004 and has been going on for 10 years. We have had 10 specifications. Thomas: There is some stuff that isn't in the core. Documents that are in the queue, which provide documentation of why and rational for the choices that were made. Thomas: There are also documents extending the standard. And more documents..(see slides) Abdussalam Baryun (AB): Is there something you learned in the process and what was difficult? (paraphrasing) Thomas: That's what the rational document is for. Folding in metrics. Security was difficult. I have a slide slow of 12 hours length explaining this; I don't know that we have time for that now. Stan: We don't have 12 hours. Thomas: Talking to slide about discusses and status of nhdp-olsrv2-tlv-extension...Adrian hit the magic button yesterday so that is going on now. o draft-dearlove-manet-nhdp-optimization: Dearlove Chris Dearlove (CD): This is an optimization on NHDP that occurred because we saw an opportunity in practice. The objective is retain information that is normally thrown away. CD: Actually it's completely legal to do already given the current draft as is. If you have extra information you are allowed to use it. It is cleaner, however, to keep the information natively within the state of the protocol. Its different if B takes a link down to A. Abdussalam Baryun (AB): I have a question regarding this draft. If I compare this to a non-optimizing draft what is the difference? CD: In terms of code there really isn't a whole lot but in terms of performance Rick Taylor (RT): First off sorry I haven't read the draft. What happens if C actually disappears when B is still disconnected from A? CD: It continues to extend the lifetime until it stops getting updates. TC: I just checked and it seems to say that. Second thing the advantage is that it doesn't do any over the air signaling it only impacts how you store and throw away the information. It does bring to the table the ability to recover quickly. It's a bit like beer. There isn't any downside. o draft-ietf-manet-olsrv2-multitopology: Dearlove CD: (History slide overview) CD: (summary of status of draft as per slide) CD: Recap of assumptions. This won't be a tutorial; we did that in Berlin. There was some miscommunication on this list about the point that each packet is sent using a single topology end to end. There was some misunderstanding on the list about this. CD: Plan. This isn't the only plan but an outline of the current plan others may want to stretch it. I personally do not have an implementation. TC: We have one but we haven't experimented with it yet. Well, we have two or three laptops running with it without crashing but nothing more than that. Abdussalam Baryun (AB): Can I have a summary of what the purpose of the draft is? CD: The purpose in one sentence: In your network you may wish to send different packets along different routes because they have different requirements and the links are different. Henning Rogge (HR): You may want to route via different routes without flooding the network. Teco: Why not make this document standards track? CD: If people implement this then it's great and I'm fine changing this to standards track if that's the case. TC: I do not think as a working group that we should go down the standards track document without many implementations as that has happened in other places within the IETF and document quality has suffered. CD: If it gets stuck in the queue for 4 years we may have enough experience that we may want to push for standards track. Rick Taylor: Is there any record of this for this draft being experimental and then changing to standards track later down the line? CD: We will post something up on the list. TC: I believe that part of the new requirements of the IESG for Experimental RFCs is to describe in the draft what the experiment is and what the successful outcome is. It is implicit that if the experiment is successful there is an opening to take it forward to Standards Track. I would not like to commit to it, because it may turn out it's not the right way. I would not like to commit to "we are letting this live for three weeks as Experimental and then go to Standards Track". Ulrich: Do you have intention to add a description of what those experiments are and what will make them successful? Adrian Farrel: Yes, he does have that intention. Where Thomas said it is an IESG requirement; it is not an IESG requirement, but a requirement of your AD at the moment. It does not have to be heavy, just what is the scope of this, how will you know if your experiment is successful, what are the possible outcomes. HR: I think multi-topology is really tricky and I'm not at all sure this will work well but it could so experimental is the correct designation. Teco: A member of the multi topology is the source destination route and I'm not sure how this helps. Could you comment on how this draft or OLSRv2 could support this. CD: We would need more information and signaling to do source-destination routing. I think we need to talk through it a bit more not a draft but there would be work that would need to happen. Teco: Let' get some focus on source-destination. Homenet mentioned using OLSR. CD: Well, our experience has been focused using multi-topology and my customers want multi-topology. If you have customers that want source-dest routing, please write a draft. Stan: We are 10 mins behind, so we are taking it to the list. o draft-ietf-manet-dlep: Ratliff Stan: I think we are in much better position now that the DT has decided to step up. Stan: Where do we go. There has been discussion on the list. One question, is it time to terminate the design team? Rick Taylor: I am on the design team. I think it could continue. I know some members have more things we want to push in your direction. Abdussalam Baryun (AB): I agree the design team should be terminated. I already see in the working group isn't active in the design of DLEP and I would like to see 20-30 people working on the document. Henning: I think it's time to end the design team as we are one step forward and we made progress. I don't think many more people will contribute. TC: If we end the design team, what is the plan forward? It has been 3 years but what is the plan. Let's not just end the DT without a plan. Stan: I agree; see the last bullet lets get this thing out before 2050. Not a misprint and I think I'm being agressive for this working group. ChrisD: What is still to be developed? Rick Taylor: I know that various members of the working group have strong options about extra work that needs to go into DLEP. Stan: If I recall, if the design team is to continue then it needs to specify a list of TODOs so that we can get to TODONE. If there is a continuation of the design team, then there needs to be a list of issues to pin down. We should be able to do this with regular discussions on the mailing list. Rick Taylor: I would like to agree but until the initial gathering of the DT, DLEP was stalling and I don't want to throw away that progress. And I think the DT did benefit DLEP. Stan: I think no question that the DT helped move DLEP forward and has really made a difference. Again for me the question going forward is do we have a set of requirements to justify the continuation of the DT? CD: I think there should be a deadline with a list of things that need to be finished. Thomas: What's missing? What is needed in DLEP? It's hard as a working group to make any decision on this without understanding of what the issues are. Rick: Where the server client are located within TCP, router driven metrics like satcom like you don't have links until you have data to send, there is a bunch of radios vendors who want their own stuff with extensions. UH: I think it would be very valuable to send this set of things to the list. Stan: I propose we come up with a list of items within 3 weeks. We will have a list of items to tackle. CD, TC: +1 Henning: We have decided to push off some of the vendor items into external extension drafts. Stan: I agree. The people involved tend to relitigate issues. We keep trying to boil the ocean. Henning: Once we have a list some of the items, we may have just to specify that some items will be pushed off into other drafts into extensions. Teco: We have talked about splitting the draft into the base spec and extensions and if we do that it will be until 2050 dealing with extensions. Stan: We have ad nauseam. Teco: Let's just get the base spec out and leave the extensions for other drafts. TC: If you have intractable issues within the design team then just push it out to the list and have the working group voice its option. CD: When dealing with extensions, if it won't work without, it should be in, if it can't be added later then it should be in; otherwise it should be left for later. Teco: I think we should move forward as quickly as possible for last call, if not this rev then next revision. Teco: I would like a sense of the room. Should we continue with the design team or not? Stan: I think we agreed that we come up with a list within 3 weeks and then we can talk about if the design team continuing or not. Teco: I want to make progress and not just push it off for longer. UH: Personally without a list I can't really make a decision on if the DT should be stopped or not. CD: I agree, I need to see Rick's list. Thomas: If I was chair, I would ask whether there is consensus to go forward with minimum base spec and extensions. Stan: My understanding that a base spec along with extensions is the way we are proceeding with. Rick: We have been attempting to make a minimal set of core specifications along with extensions. Ulrich: Who is in favor of having a minimal set of specifications with extensions documents? Many hums for base with extensions in extension documents Ulrich: Who is in favor of having some extensions included in the base specification? One hum Rick: There was a second hum from jabber for the second option. Adrian: Reminder that the design team is acting as agents for the WG. If you don't like their output, the WG decides, not the design team. o draft-ietf-manet-aodvv2: Perkins Charlie Perkins: Status of aodvv2. RIOT: OS for internet of things. Code is portable to Linux, Freie Universitaet in Berlin. Implementation of AODVv2 on that. Using HR's RFC5444 parser. RREQ, RREP working. ND and RERR are implemented, but it needs to be tested more. Linux implementation is to use tun/tap interface, available on all recent version of linux. HR: I track to track down when tun/tap is available. Kernel 2.0 has tun/tap. At some point someone wanted to write VPN, used tun/tap. Available on all versions. CP: Previously there's an aodv-uu implementation, still in use, but requires to be a kernel module, not as portable. Hope to run it pretty soon. Testing on ubuntu, soon on Fedora and others. Websites to look at the code online. Biggest change since previous version was after many suggestions to delete AddedNode feature. Included originally for compatibility with DSR. WG was originally chartered to combine DSR and AODV. Once you have route discovery anyway, it's not clear whether having additional info really helps. Can be Detrimental for performance. Hard to decide when to include addednode info. Not much against removing it. Can be re-included. Other mostly editorial changes. Terminology was made more consistent. Lexical improvements. bibliography. Ancient changes sections removed. Issues raised: clearly show that idle route was used to be marked as active. Other issue, when to expire a route. For the case when you have an explicitly timed route, previous language say it has to be expunged. No real reason if you want to be able to test it against future routes. Could be done either way, see discussions on the mailing list. That should be resolved quickly. See github and bitbucket repos, riot is there, linux work needs too much work to distribute yet. If interested contact me. Someone suggested a python implementation, encourage that. Next steps: couple of open issues, RIOT code and linux code need to be finalized. NS2/3 simulations. Right now AODV implementation existing. Future: interested in testing with MPR or other CDS instead of classic flooding. No real reason you can't run AODV and v2 on the same network, to test. Questions? TC: Plenty. Slide 3, why are you re-implementing neighbor discovery? CP: I'm not, I think they're doing it for the system EB: It runs on top of 6lowpan TC: Ah, so it is lowpan-nd (RFC6775). 2nd comment, slide 6. Not sure compatibility is understood with AODV and DSR. Seems to be removing something that was there for compatibility is very misleading for the WG. I have implemented DSR, would not be compatible either before or after. Compatible if they can operate together. CP: Compatible is the wrong word here TC: Slide 10. Since Maastricht I have (not only I) posted numerous reviews, and I'm sad to observe not a single issue I have said in the past has been reflected on this version. It leads me to conclude the DT is not reflecting the comments and desires of the WG. I think it's an issue the chairs need to address. We're not at a more publishable state than 3-4 years ago. SR: Not aware of a DT, there's an editor team TC: Correct, Editor team then. SR: Got it on your second comment, I hear you TC: I'd say there is no reason for the WG to continue looking at this given than the comments are being ignored. CP: I have addressed your comments TC: Saying you were not interested in discussing these comments. See Jiazi's email for example. The authors of the document said "I'm not interested in discussing these comments" CP: Those words did not come out from my email client. Anyway, I dispute that the document does not deserve further review as it has already benefited from such JY (jabber): WG comments have not been addressed. Most of the comments have been there for years. CP: I'd like to get some more specifics about that. Juliusz Chroboczek: 'Compatibility' -> ''. Glad to see you have 2 implementations. For many years a lot of people have tried to play with aodv, a lot of problems with that. The kernel does not have the necessary APIs. The proactive routing protocols do not have this problem. You're cheating by having everything tunneled through user space. The only way would be to actually design the kernel interface that you have and push this on the mainline code. CP: So OLSR clearly progress. In the case of reactive there a while we came across this way of combining the design space, idea of have the two protocols compatible in design space. 2nd comment: I believe that in some case even in proactive case you need kernel support. SR: 4 minutes left CP: I am not going to continue right now HR: The idea behind tun/tap is not to tunnel everything. Only default route points to user space through tun/tap, if you don't have a route for it. JC: How do you handle error case. CP: Only when route lookup fails Abdussalam Baryun (AB): I think editor team's doing a good job. I hope this continues so we can progress and finish this within half a year. JD: First I'd like to say there are implementations at this time. Unfortunate that it's at least a month out. We are very far behind on where we wanted to be. Dunno where that leaves us. Your presentation makes be apprehensive of what's been playing around. TC: 21 january 2013 SR says "[...] the spec needs to change". On the same day was the email from CP saying "I'm not interested in discussing this right now". Only at this time having implementations is questionable. I formally protest against the fact that it's allowed to be going forward with that process RT: I agree with Justin. No horse in that race, but this looks like an experiment. Not ready for standards tracks, how you implements this, how does that works. Just doesn't feel right. CP: There's been a lot of publications on AODV, v2 is quite close so very well understood. o draft-rogge-baccelli-olsrv2-ett-metric: Rogge Henning: formally ett-metric draft was renamed to remove confusion Henning: It tries to estimate the unicast airtime messaging. Henning: What are the components of the metric. It measures loss, using 5444 sequence numbers (packet) which is nice because if your network gets larger with more TC you get more accurate link metrics Henning: If you don't have sequence numbers you can use lost NHDP Hello messages Henning: There are other ways to figure out links like using unicast routing although I have concerns about this specifically possible route flapping due to measuring of unicast only when traffic is there. Henning: Link speed is another component that is obtained from an external source. Henning: There are a couple of open questions. How to distribute the numbers. We can going from 1 bit per second to 1 terabyte per second and contain full loss rates. Henning: We have 24 bits and we need to figure out how to fit this information into these bits. Henning: This is open for discussion and we have a proposal, but comments are welcome. Henning: Should this document be adopted by the working group? If so it should be experimental? Henning: I have a few comments from people who couldn't get things compiled but I haven't heard anything from people who actually got it working and their experience with it. Teco: Thank you for this work. Loss ratio Henning: If you have a way to do this then you should write a draft. I have had some colleges who tried to do this and had a hard time with it. Teco: Second unicast traffic measurements is difficult because you only get speed numbers based on the amount of unicast traffic which is traveling on the channel. Discussion about probing and how it can be used to generate speed values. Concluded that it may be good to include probing technique in an appendix. Abdussalam Baryun (AB): I think it should be adopted. Juliusz Chroboczek: I don't think 0-.75 is enough range for the loss rate. I think we need at least 90%. CD: I would like to disagree with the previous person that this is for OLSRv2 and that 90% won't work. Aaron Kaplan: The loss rates do happen in practice though which are much greater than 90% CD: I think that if your designing this to use OLSRv2 metrics then we need to do experiments to see how it works with (off the shelf OLSRv2 my paraphrasing) Henning: You could use use this as type 0 and this will work. TC: I think we need to get these documented so that we can get them out and get people using them. I think this should be experimental track. I think its interesting that you're basing this off of real work experience. How far off is this from what you are using in the real world? Henning: The way we measure the link metric using hello and sequence numbers is the same although the encoding is different. Packet sequence number measurements are pretty good in practice. TC: It seems to me that this isn't something that you are pulling out of your sleeve and it is a well written document. Rick: You wrote this for OLSRv2 but could you specific the way to specify the way to calculate the metric but put the mathematics of encoding the metrics in a bit field are put into a different section of the document. Henning: The document is written that way currently. Rick: Is this going to target just a good way to calculate a metric or will this just be an OLSRv2 type document? Aaron: I just wanted to comment on where we are working in the community networks. We are polling the wifi cards like a 1000s per second and we compare those values to the calculated values we are using here. We have access to the source code and Henning has been very helpful. We arrived at these metrics because thats where our experience has brought us. UH: If you have any document, please send it to the list. Teco: This is informational as there is no protocol here. The specification here is how we get some information from the local radio and translating it into a dimensionless metric. Henning: Exactly this is a plugin into the unit-less metric included within the OLSRv2. Teco: I don't agree with the metrics values as presented as I would like different. Henning: Different people will want to use different values but we need a default. Teco: Agree a default is warranted Henning: It will also not break anything if different values are used as the values are unit-less so the routes might be crazy but they will work. TC: I think experimental is exactly the place for this document Emmanuel: I would like to comment to Rick's earlier comment about if this is related to OLSRv2. It uses building blocks such as sequence numbers in RFC5444 and missed NHDP HELLO messages to calculate the metric, so in that regard it could be used with other protocols and is not only tied to OLSRv2. CD: There needs to be a section describing the experiments. TC: I think that scoping this down to an experiment with *a* well-known standardized routing protocol is a good thing. I think going to other protocols is interesting, but it's not the same experiment, and the same metrics are not appropriate in the same way in different routing protocols. I encourage to focus on one experiment and do that, and then maybe run the same against other protocols. Henning: For AODV this metric would be a problem as there isn't normally control traffic or any unicast traffic on a link, so there is nothing to measure. Stan: Hum if accepted as WG document? hum in favor, nobody against. Stan: to be confirmed on list. o draft-gerla-manet-odmrp: Colin de Verdiere draft-gerla-manet-odmrp-asym Axel Colin de Verdiere: Slides being presented are "Old" slides. (Slides on web site may differ?) Axel: Protocol consists of two messages Join Query by sources and Join Reply by members Axel: It was a complete re-write of the 2002 version. It uses all the building blocks made in the past 12 years. Asym-ODMPR Axel: Presentation... Request comments on the draft. No comments as there was no time. Take comments to the list. o draft-clausen-manet-olsrv2-management-snapshot: Herberg UH: Presenting. Requesting WG adoption o OLSRv2 + RFC6971: Clausen No time for presentation (slides in the proceedings), brought to the mailing list. Request by Thomas Clausen (after the meeting): "It'd be kind if the minutes contains a link to the message which Ulrich started and wherein the discussion was brought forward: In the new "archive format" (which I am given to understand is being reworked to show the threads) that'd be: http://mailarchive.ietf.org/arch/msg/manet/Loj8AP3uxKExI5NPbafy5Vet9ek or, the format that actually allows seeing the threads, and which is useful currently: http://www.ietf.org/mail-archive/web/manet/current/msg16016.html "