MANET WG Meeting Minutes Meeting : IETF 81 Tuesday July 26, 2011 Times : 1520-1700 Afternoon Session II 1710-1810 Afternoon Session III Location : 208 AB Chairs : Joseph Macker jpmacker@gmail.com Ian Chakeres ian.chakeres@gmail.com Secretary : Ulrich Herberg ulrich@herberg.name Scribe : Justin Dean Minute-taker: Thomas Clausen, Ronald in't Velt Jabber : xmpp:manet@jabber.ietf.org Audiocast : http://videolab.uoregon.edu/events/ietf/ URLs : http://www.ietf.org/html.charters/manet-charter.html http://tools.ietf.org/wg/manet/ ========================================================= AGENDA o Administrivia - Mailing list: manet@ietf.org - Scribe(s) - Blue Sheets - State your name at the microphone - IPR o Bash the Agenda o WG Status/Overview: Macker - Recap of Documents/Status - Announcements o SMF Status: Macker - draft-ietf-manet-smf-12 o OLSRv2 Metrics Discussion: Clausen - draft-ietf-manet-olsrv2 o DYMO, SMF, and REPORT MIB Discussion: Cole - draft-ietf-manet-dymo-mib-04 - draft-ietf-manet-smf-mib-02 - draft-ietf-manet-report-mib-01 o NHDP and OLSRv2 MIB Discussion: Herberg - draft-ietf-manet-nhdp-mib-08 o Security Document Updates: Herberg - draft-ietf-manet-packetbb-sec-04 - draft-herberg-manet-nhdp-sec-02 o DLEP Updates: Ratliff - draft-ietf-manet-dlep-01 o Open Microphone - Discussion, Related Work & Announcements - Interops, Implementations, Other Items MINUTES: Chair: Introduction / agenda bashing DLEP author not here, participating remotely (Stan Ratliff), others as well, mike reminder, note-well reminder. Rough agenda presented; fairly efficient meeting. Lots of documents in process, either being in reviewed or rewritten. OLSRv2 just released, may not have been read as it was released this morning. We will go through these main documents, that is the main purpose of this meeting. SMF updated, will go through those updates. Other documents have been released, updated or adopted as WG documents, or have been reviewed and revised. Joe Macker will present DLEP on behalf of Stan Ratliff, who could not be here. Satoh-san: What about DYMO? Chair: Get to that. High-level things. Ian Chakeres (co-chair) has been unable to attend meetings, his job has taken him away from his co-chair work. Looking for replacement; Ulrich Herberg has been WG secretary, assisting quite frequently. Hoping to have soon a co-chair replacing Ian. Adrian Farrel (RTG AD): Has been intention since passing news on to ADs to identify a new co-chair before this meeting, has been hard to get enough bandwidth to get talking to the different necessary people. Hopefully within a week or two it will be done. Joe: In the meantime, we are here to do the work. Stan Ratliff (from Jabber): Willing to volunteer as co-chair as well. Joe: On to DYMO. Related to Ian as well, he is main co-author. Long list of comments came from the community - important to address. Authors not willing to commit necessary time to rewrite/update. We can, if somebody wants to step forward, re-spin the document. If somebody is really interested in DYMO, please do step forward. Currently it is in "parked" status, there is nobody committed to work on it, and we will wait and see if there is any interest in that. Joe: Document Status for SMF v12 has been released before the deadline. Huge editorial sweep done, lots of comments, had help on editing and believes that they are addressed somewhat to satisfaction. Thinks that the readability, definitions have improved dramatically. It remains an experimental document, but it still is better. Adrian had a comment currently, which needs to be addressed, I have not had time to do that yet but I will get to that. There was a processing table error, which got pointed out and which was fixed. Also, there was MD5 specified as hash function, but as it is deprecated we have changed to another hashing algorithm. Adrian had an IANA question, which I think is answered satisfactory. Adrian had another question regarding DPD (hash-based vs. ID based), and as to if or how it can be detected. Should we define a default mode of operation? Joe thinks that ID based should be default mode. Adrian: It is experimental, and we should not make a mountain out of these comments. Intended as a "have you thought about that?", and if you say "Yes, we do not want to do anything" then that's OK. Joe: Actually a good comment, and probably want to make that explicit. Adrian: If this was std. track, the default would be important. As an experimental draft, not so important but it may be good for implementations for experiments and interops to have something to test again. Joe: I do not have a problem making I-DPD default at this point. Teco Boot: I do not think that it is that important. SMF routers all have to have duplicate detection; can each node choose how to implement? Joe: There is something behind-the-scenes stuff that may necessitate that all devices are in the same mode. Teco: Let's assume that we have a network where some use hash-based, others ID-based. Does it break something? Joe: We have slight concern on that. Brian Adamson: Hash-mode and ID mode are not compatible. Hash-mode depends on the HAV generated from the packet content, so it may not guarantee a unique identifier in the ID. Not colliding is guaranteed by HAV, but not by ID-based mode. Joe: Maybe Teco could do a review, and let us know, be happy to read it again. Brian: Some protocols are not necessarily conductive to hash-dpd, whereas HAV or I-DPD can disambiguate this. Joe: If this was to go std. track, I would actually split the document up into a v4 and v6 spec, as they are different in terms of robustness. Thomas Clausen: New version (-12) of OLSRv2 uploaded. Same functionality as version 11 but with metrics folded in. Slides are taken from previous IETF presentations. Straightforward to add metrics into the document and we did it because it could not be done in the future. OLSRv2 does not describe how to calculate the metric value, only how to use it. The draft supports both directional and dimensionless metrics. HELLO messages are modified by additional TLVs being included. Implicit default values are supported allowing for hop count without incurring overhead. MPR selection is metric aware now. Section 18 and Appendix A need work. Expect version 13 soon (~2 weeks after IETF). Joe: Strongly advises people who care about metrics to take a look at this document. We waited a long time to fold them in, so we need to make sure we have the right people look at this. MPR election adds some complexity so I understand why it has taken a while. Thomas: Again new draft coming soon. Bob Cole: Updated NHDP-mib, WG LC finished, lots of comments from Justin, a few conference calls. Justin has reviewed it once more, has some textual comments, suggestions, but is mostly satisfied with the recent updates. Added nhdpLibLocalIfSettable, clarified the use of discovered router index, neighbor interface index locally defined to index tables. Changed some counters to 64bit to avoid wrap-around. Also, some other details. Had discussion with Dan Romanescu (OPS AD), suggested once ready and in WGLC to send to MIB doctors for a different perspective. It does compile, but otherwise no reviews other than Justin's. Justin: Once the changes I have suggested today are included, I would encourage that it goes forward. Encourage that others look at it. Joe: What is the approach of the MIB doctors? Bob: Dan suggested that once in WGLC the MIB doctors should review the draft. Ulrich Herberg: Dan suggested a 4-week WGLC, and doing MIB doctor review during that period. Expresses his gratitude for Justin's review. Suggests that a new WGLC be issued, and that it be submitted to MIB doctors. Adrian: Sounds like the right way to do it. It will go to MIB doctors during IETF LC, but you do not want major structural changes to be done during that time, so sooner is good. MIB doctors may be a bit slow to get started, so use an AD who is a little pointy to wake them. Bob: Think that we can do a -09 this week, then go WGLC and push it to the MIB doctors. Justin did a great job. I started implementing the front-end of the MIB in Maastricht, but would like to discuss with Justin to integrate with his code. Ulrich: Do you suggest that we do a 4 week or 2 week WGLC? Adrian: Very tempted to say "yes" to that question. Point of the WGLC is to collect comments from the WG. Chairs set it as long as they need. I would not specifically bother whether the MIB doctors respond during the WGLC, they are kind of a separate issue. If they produce substantial comments, they will get it back to the WG for another WGLC. Joe (Chair): There is a requirement that routers going std. track that they need a MIB. MANET devices often are embedded, SNMP? not always needed. Thomas: RPL (ROLL) did not need a MIB, can Adrian clarify the requirements? Adrian: It is no longer a requirement for routing protocols to have MIB modules but it is still useful to have them as it provides data structures. What is a requirement is what needs to be configured. Joe: For us it is largely a structural piece and not every deployment is going to be able to use SNMP. Adrian: The core working group has some of these issues, and some ideas of a "reduced MIB". Bob: NHDP has nice data structures already so the NHDP MIB module did not add structurally gain. Bob: Two other MIBs (OLSRv2, SMF) awaiting that these documents settled down. Want to talk to Juergen Schoenwalder on lightweight MIB. Bob: Report-MIB - some discussions in Prague as to simplifications. Essentially, it is a proxy-mib, for example you can have one MIB entity in a vehicle that you can query, and that MIB can then query other devices. RMON report proxy, for example, liberally stole from the RMON control structures. Right now, however, it is WAY too complicated -- 11 different conformance groups, in my mind that is ludicrous. The reason it turned out this way is that it provides different reports: statistics, samples, history. Want to simplify to one, then see if we can expand on it, if there is interest in expanding on it later. Suggests periodically sampled data, as that is what RMON has experience with. Wants to ask the group if this is a sane approach - to pick "samples" for now? Joe: Anybody have comments? Wish I could have all 3 without the complexity, but as you have brought it up and I believe that you are correct, then I think that the recommendation to do samples is reasonable. I have a chair-question: given what you have been saying, should it be experimental or std. track? Bob: I would prefer experimental. Joe: That seems reasonable, unless Adrian has any comments on this. Bob: I have no desire to implement something so complex, I would implement only the samples. Joe: When you revise it, change it to experimental. Ulrich: Relationship between NHDP-MIB and REPORT; not normative but still. The MIB module itself (NHDP-MIB) would not need to be changed, there are some textual changes to spin when Justin's comments are folded in. Joe: On the list. Bob: How long should we wait? Joe: Let's just go ahead; we need some experiences with it. Ulrich Herberg: Had a WGLC, got substantial comments from Chris Dearlove. Believe to have addressed all, submitted updated version before the cut-off. Decomposition of signature into crypto-function-over-hash-value-over-content. Chris' comment was that there were other ways of doing signatures, and these should be supported. Hence, changed similar to the timestamp-tlv, make a more general framework by way of using the TLV-extension 0. Gave one example in appendix as to how to do the signature over hash by way of TLV-extension 1. Believe this to be more general. Got email from Chris that he is mostly happy with changes, have some minor comments of an editorial nature. Ulrich suggests that these should be folded in easily, and requests that a second WGLC be done. Forgot to rename the document as otherwise suggested by Teco; this can/will be done. Thomas: Was it just the title of the document or the document name itself? Teco: keep the draft-whatever name, just the title. Ulrich: Currently, individual draft, Joe called for WG adoption, Joe do you want to comment? Joe: Seemed logical to adopt as WG doc, unless there were any issues raised? Any issues with adaptation of this? Ulrich: Currently, needs more work, but it should be ready for the WG. Needs some more reshaping to packetbb-sec, but wanted to wait before incorporating that until seeing if it was to become WG doc. A few other drafts, notably sec-threats describing some potential security vulnerabilities, need some work. OLSRv2-sec document in the pipeline. Joe: They can be individual documents and not working group documents Thomas: They can be informational or experimental, but if they go through the WG then more eyes will know about it. We should try and make it go through the working group. Joe: Are some of the threats specific to NHDP? Thomas: Yes. They are illustrating NHDP security threats and not wireless threats in general. Thomas: I really think it will be a good thing to have people who implement these things to see what we are discussing and hopefully get feedback so that we can more fully cover current threats. Joe: Do you want the working group to look at the NHDP threat document? Thomas Yes after a next revision. Joe: Come to me when that happens. Thomas: OLSRv2 once it is stable these are things we would want to work on. Joe: That sounds wise. Joe, channeling Stan Ratliff.: Very few comments on the mailing list; Tom Henderson had some good comments that will be folded into next rev, notably about dealing with state machines. Joe, as a chair, would like to see how DLEP could be a framework document that people can write extensions to; lots of different media, interface behaviors and thus different requirements. This document is good as a framework that people should go forth and write extensions to. Hoping to get feedback from WG as to how this document should be shaped with this in mind. Teco: Happy to see some progress on link metrics, in OLSRv2 and DLEP. Think this is important work. Do we need to check if OLSRv2 and DLEP are aligned? DLEP is a much broader approach, may also apply to OLSRv2. Some comments are more detailed - in OLSRv2 the metric is defined by the receiver. Comments from Stan: OLSRv2 deals with how to use of metric, DLEP with how to get the metric. Tom Henderson: Are we going to have DLEP define standard things like bandwidth and then have specific radio type TLVs etc.? Joe: Would like to consider this as well - radio version of DLEP instantiation, how would that be? Stan: Good question, we should probably take that to the mailing list. Tom: What becomes of the credit flow control that is in RFC 4938, which I do not see present in DLEP? Joe: I do not know that, we need to see what Stan has to say. David Ward (MIT, not the ex-AD): I realize that I have not read all discussions on mailing list. The way we see these standards being used; not one radio type being use with a router, but multiple radios being used. Relative link quality etc. are very implementation specific, and not something that one may compare easily between different interfaces. With the extended field, would one be able to replace, for example, relative link quality to something with a little more meaning? Joe: Queuing up questions for Stan. Justin, channeling Stan: The Sub-TLV: regarding the flow control in RFC4938: the purpose is to put credit support into future DLEP. Optional and per neighbor basis. Will come in future version, forgot to stick that on slide. Regarding specific radio types with specific metrics - depends on how they specify the specific sub-TLV type. Joe: Somebody may be interested in developing requirements documents. David Ward, you seem to want a heterogeneous solution. David: We have vehicles which want to connect to satellite and two different terrestrial radios, using multiple radio-to-router protocols running. Stan: Open to any addition metric types, let's get that on the list Want heterogeneous solution, but also allow for vendor extensions as well. Joe: Out of agenda items, we want to stop here unless there are any open-mike things. Speak up. Ulrich Herberg: Any OLSRv2 Interops planned? Thomas: Yes Justin Dean: Would like to give short update on NHDP implementation; open-source, freely available on cs.itd.nrl.navy.mil Support for class-based packet building, multiple addresses per interface recently added. Interop with NHDP implementation from Vienna (OLSR.org) Thomas: Thanks to Joe and Ulrich. We have been analyzing security for NHDP and OLSRv2 also SMF has the possibility to be used in a big way. We should be looking into security relating to SMF in the working group. It would be good to consider it not to slow down SMF but as a complimentary effort. Joe: If you look at the SMF document you might say it really is simple. The relay set thing is in there but that has been done in this group before. More interesting is layering on top of SMF with group control and other methods. I am using it myself for multi-hop mDNS which is an interesting way which allows for bootstrapping the network. If other people are willing to write more documents I am more than willing to take that on. Ulrich: It might not be the right time to bringing it to the working group but it should be something that people are thinking about. Joe: We don't want to be restrictive here so please anyone willing to work on security. Thomas: There is another working group which is working on a similar mechanism (to SMF), and it would be good to have these other things discussed in the same context. Joe: I would hate to bring it back into an experimental approach. Thomas: There are at least 3 groups in the routing area doing similar things. Joe: Similar but not exactly the same. Thomas: We should look at the other groups to make sure that we are aware of them to discuss the different approaches and the trade-offs between them. Joe: There are things related to persistent and reliable delivery. Ronald in 't Velt: Interface SMF with infrastructure multicast? Joe: Tom Henderson has done something, Tom can you detail? Do not know if any of this is publicly available. Tom: There may be MILCOM references, I will look at that. [ Tom provided the links to the papers on the mailing list: Chakeres, Ian D.; Danilov, Claudiu; Henderson, Thomas R.; Macker, Joseph P.; , "Connecting MANET Multicast," Military Communications Conference, 2007. MILCOM 2007. IEEE , vol., no., pp.1-7, 29-31 Oct. 2007 Danilov, C.; Henderson, T.R.; Spagnolo, P.A.; Goff, T.; Kim, J.H.; , "MANET multicast with multiple gateways," Military Communications Conference, 2008. MILCOM 2008. IEEE , vol., no., pp.1-8, 16-19 Nov. 2008 ] Joe: We can do a best practice document as to how we interface with PIM - is that something we would think useful? Ronald: Remember that there was work on this way back. Prerequisite to sort this out was SMF to go to std.track? Joe: Probably, yes, we certainly want to specify that. If somebody wants to write up a best practice document right now, then that would be good. There is probably not one single approach to how to do that, though. Ulrich: Sign blue sheets. Joe: Please pass them to those who have not signed. Thanks for coming. One of the most important things we do is to look at the metrics documents and DLEP. Thomas: There is no metrics document, it is now OLSRv2. :-) 16:49: Meeting Adjourned.