MANET WG Meeting Minutes Meeting : IETF 80 Wednesday Mar 30, 2011 Time : 0900-1130 Morning Session I ========================================================= 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 - High Level Overview of Documents/Status - Announcements o SMF Update/Editing Status: Macker - draft-ietf-manet-smf-11 (posted) - mostly clarification and removal of unnecessary material - addressed posted comments from Herberg - initiate another WGLC o OLSRv2 Discussion: Clausen - ID needs update, Metrics support inclusion 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-olsrv2-mib-03 - draft-ietf-manet-nhdp-mib-07 o Security Document Updates: Herberg - draft-ietf-manet-packetbb-sec-03 (updated) - UPDATE TO draft-herberg-manet-nhdp-sec-00, WG adoption? o DLEP Updates: Ratfliff (macker proxy, Ratliff via jabber) - adopted as WG doc - draft-ietf-manet-dlep-00 o Funkfeuer and other wireless community network deployment and experiences with MANET: Aaron Kaplan - http://www.funkfeuer.at/ o Open Microphone - Discussion, Related Work & Announcements - Interops, Implementations MINUTES: Joe Macker provided an introduction and overview to the agenda. High level WG status of activities and document was provided. It was discussed that olsrv2 and demo required updates. It was announced that demo was in parked status since authors had not indicated any intention to update the document. olsrv2 is presently expired but authors intend to provide an update with metrics inclusion. The authors have mainly been busy with working on the nhdp document which is in AUTH48 status. Question from Bob Cole: If DYMO document is "parked" is MIB doc also parked? MIB document is not as controversial with comments to be addresses but they are linked so yes this makes sense. It is not presently clear if authors will reengage this document. Justin Dean: OLSRv2 status, working on document focusing on adding metrics support, but no new document to review at this time. There was a discussion of various WGLC intentions for present documents including MIBs. Bob Cole: I was hoping to have some discussion around re-architecting the "Report" MIB. Would like to simplify it. Has become complex. Joe Macker: Will discuss later in the meeting. PacketBB-Sec document may be ready for last call. Bob Cole: Looking at the charter, it looks like all work on charter is almost done. Beyond that what are future MANET working items. Joe Macker: First thing is to get a routing protocol (eg. OLSRv2) document and related fundamental document advanced. Future items may include border routing solutions and approaches (e.g., SMF / PIM gateway definition). There certainly has been work done here. Henning: Comment on packetbb-sec. When started we talked about adding TLVs for message encryption. But was dropped. Maybe document should be named "packetbb-auth" instead? Ulrich: I think that is a good idea to make it clear it is mainly about authentication. Announcement that packetbb-sec document was updated yesterday Intending for Ulrich Herberg to formally help with MANET working group logistics initially as WG Secretary. We will pursue formalizing this in the next week or so. Joe Macker - SMF status v11 of ID has addressed a large number of comments from WG mainly including Urlich Herberg's thread. The thread responses were also posted to the list for review. Ulrich: Thanks for including my comments. Have reviewed new version in detailed manner and have identified only nits and editorial comments that can be addressed in WG last call. Clausen has reviewed document too and also thinks it is ready for WG Last Call. We will likely pursue another WGLC beginning soon. Please try to provide comments within the 2 week SMF WG Last Call to be issued. Ulrich Herberg - NHDP and OLSRv2 Status Editorial comments on NHDP being addressed during AUTH48 see no significant issues to hold off publication. OLSRv2 updates have been on hold until NHDP completion. Authors now ready to proceed with that work. Henning: There was one revision of NHDP at IESG and "heard" there was a "problem case" that was addressed. Ulrich: Suggest you ask the authors on the mailing list (Henning had commented the specifics of problem case was unclear) Henning: Could the authors post a description of this and clarification (details) to the mailing list? Bob Cole - MIB Update MIBs have been updated to be consistent with NHDP Bob: Need closer review of the MIB documents, especially from protocol authors and implementors. Bob: Believes NHDP-MIB is ready for last call review Henning: How to handle changes in HELLO protocol with addition of metrics of OLSRv2? Will the NHDP-MIB be extended? Or how it will be handled? SImilar question for MPR lists, etc Bob Cole: MIB is aligned for NHDP only Ulrich: No need to change the NHDP MIB. Need to put it into the OLSRv2 MIB instead of changing NHDP MIB Bob Cole: similar to some extensions that are being done for the SMF MIB? Bob Cole: DYMO-MIB will be "parked" in conjunction with current DYMO status Bob Cole: SMF-MIB is for SMF but not specifically for the relay set algorithms. So for each relay set algorithm MIB extension may be needed. Brian Adamson: SMF is Experimental RFC so the MIB document should be also Bob Cole: Yes. Fine for SMF-MIB to be experimental Ulrich: If document is ready, it should go to WG Last Call before extensive review by MIB experts. Macker: Each NHDP author should review the NHDP MIB Discussion of REPORT-MIB and delay WGLC for simplification of document. Macker: So you're saying to reduce the number of reporting models and rewrite doument? Bob: Yes. Macker: I'm OK with this ... hopefully this reporting is not duplicative of other work. Bob: Does not appear to be duplicative. Reporting MIB has not been previously developed in IETF. Ulrich: If we strip this down, will we then have several report MIB documents in future? Bob: We can strip this down to a "Statistics Report MIB" and then if need for other (e.g. "Sample Report") is identified in the future, we could have another Report MIB document .... Strategy here is to scope this down to get it done and get some experience. Joe: Had liked the Sample Report ... needs to think about this proposal. Perhaps some additional discussion. Bob: We won't discard the work, but "postpone" it to focus on more scoped simple reporting for now. Henning: Most stats is done from a central server in our deployment because most nodes are lightweight and don't have SNMP on most all nodes in their deployment. Macker: Yes, embedded devices may often not have SNMP to be lightweight. But doesn't change the question of what is important to collect for reporting and what the priority should be. Bob: The architecture could allow for proxy of SNMP Aaron Kaplan: Have different stats they keep. If you lose a node important, routing table inconsistencies, and radio stuff (Signal-to-noise, etc) although not part of this MIB? Bob: This MIB is independent of the counters being kept. More a question of statistics or samples of counters. Ulrich: Concerned if we strip out the statistical part since NHDP MIB keeps some of these? Bob: NHDP-MIB does not reference the Report MIB. Bob: If the group is more interested in Statistical vs. Sample data is a question. We need to determine the priority to simplify the current document. Ulrich Security Related Documents Ulrich: Some security considerations in NHDP, but need a document that describes authentication signature, etc that would enable implementation of some of those considerations Alex: Would these documents work together? I.e. NHDP and NHDP Security? Macker: Yes. This would be an extension to NHDP. Alex: This makes sense. Macker: Do you plan to work on security threats document soon (expired document)? Ulrich: Not immediately, but if there is interest can be revisited. Other Discussions Macker: Will pull back idea of WG Last Call on REPORTS and should discuss more scoped functionality on the mailing list. Macker: WIll issue last call for SMF document Ronald: Problem presented in Beijing with respect to multiple interface operation. Dean: The current algorithms included in SMF were initially designed with single interfaces in mind. As Joe mentioned they work with multiple interfaces but miss optimizations. Adamson: Added relay set algorithms may be specified as separate documents in future to specifically support multiple interfaces, etc. This may happen as experimentation progresses with SMF. Ratfliff - DLEP Joe Macker proxied Stan Ratliff slides for DLEP status (see slides) Boot: Dual-stack issue. Had asked the question previously instead of dual protocol instances could handle better so this is a side remark with respect to more efficient dual stack. Ratliff: The current implementation allows for signaling all addresses in a single message. Use of address blocks may cause multiple messages to be sent in a dual-stack environment. Teco: For example, packet-bb is limited here. Dean: Depending on ipv4 addresses it might not be a bad idea to encode them with ipv6 addresses as the head of the address will be compressed out anyhow. Henning: dual stack issue: Could define a prefix in packet-bb form to differentiate address families. Macker: perhaps a good idea. We should write these down. Ratfliff: Yes. The problem is that only 1 address family per message is supported in RFC 5444. Tom Henderson: is the intention to put everything into a single document or will there be separate profiles for different radio technologies, etc? What is the plan for this? Ratliff: Long term, there will probably be an update to add TLV's for newer radios. However, we've tried to incorporate all functionality in the current draft. Ratliff: If Tom has more features/functions that could go into DLEP, we'd be interested in looking at it for inclusion. Tom Henderson: Some things not addressed. Should this be handled as radio-specific functions in separate document(s) or attempt to put everything in the DLEP specification. Ratfliff: Tom has a good question. Sounds like something for the mailing list? I'm looking at 2-3 weeks for the next version. Kaplan: Presentation of Community Networks Deployed and use of MANET (see slides) What financial sustainability model are you using in order to build/maintain your community networks? Aaron: first sponsored by ISPs, now maintain a colocation center for servers and "uplink" access. The server housing service supports the wireless mesh community network (i.e. the fees for the server housing service provided by the colocation center) Macker: Hazy site / fisheye ring size for deployments? Henning: multiple, 2, 8, 16, ... Adamson: would issues related to multiple wifi links associated with a "node" be something that a specification like the DLEP proposal could somehow help address? Aaron: perhaps yes. Henning; no exchange of metric data between different protocols (in response to Macker question regardless heterogeneous protocol interconnection some of these networks) Adamson: Is load balancing or similar used to achieve higher capacity across "backbone" of network? Aaron: yes there is some experiementation in Vienna with an associated OSPF backbone network? Teco: Is my address mobile across different parts of the backbone (ie keep my address) Aaron: yes ... Macker: If you go past the BGP edges your address won't reach ... need to stay "within in the cloud" Aaron: can keep address across the city ... mesh works over the entire mesh. In guif.net , they have separate areas ... Teco: 2-3 thousand nodes within same area Jorjeta Jetcheva: Do any of these use multi-radio nodes? Aaron: yes some are in use. Jorjeta: not a big requirement? Aaron: 802.11n and directional antennas help alot. Omni doesn't scale well. Tom Henderson: are there publicly available data sets that can be referenced? Aaron: we have topology files that are accessible. These are "live" topology. Nodes are static but the network is dynamic. Would like to have more data such as SNR, retransmit stats, etc available Samita: Mention of coding improvements. Is the code available? Aaron: yes - in the olsr.org code base. Can checkout from repository. Side discussions of shared systems and regulations,etc. See jabber logs or voice archives. Ulrich: Plans to update to OLSRv2 and how to go about this? Aaron: good reasons for following the standards. Would like to see good work done here. We're still an experimental network so welcome exchange with the community. Aaron: in response to AUP question ... some starting points are in the Pico Peering agreement ... it comes down currently to "if you screw up your neighbors will block you" Number of actions and discussions to bring to list. - WGLC of several documents. - Acceptance of NHDP security related docs - Further discussion simplification of REPORT-MIB work - Discussion on list of metrics and olsrv2 modifications for next revision - Further evolvement and revision of DLEP work