MANET WG Meeting Minutes Meeting : IETF 82 Wednesday November 16, 2011 Times : 1300-1500 Afternoon Session I Location : 101 D Chairs : Joseph Macker Stan Ratliff Secretary : Ulrich Herberg Scribe : Axel Colin de Verdiere Minute-taker: Justin Dean Jabber : xmpp:manet@jabber.ietf.org Audiocast : http://www.ietf.org/audio/ietf82/ 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: Ratliff - Recap of Documents/Status - Announcements o OLSRv2 Discussion: Clausen - draft-ietf-manet-olsrv2-13 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: Cole - draft-ietf-manet-nhdp-mib-10 o Security Document Updates: Herberg - draft-ietf-manet-packetbb-sec-07 o DLEP Updates: Ratliff - draft-ietf-manet-dlep-01 o Radios, SatCom and Considerations: Cole o SMF: Dean o Open Microphone - Discussion, Related Work & Announcements - Interops, Implementations, Other Items MINUTES: Stan Ratliff: note well for the MANET Working Group. Overview of agenda. Justin Dean: requested discussion time for SMF way forward. SR: Bob Cole (BC) requested time for presentations as well. SR: Status of WG documents: OLSRv2 one or two minor nits, then we can go forward. DLEP has expired, we will resubmit ASAP. DYMO-MIB is not currently worked on. NHDP-MIB needs to be moved forward to the IESG. I am working on moving that forward (write-up). Ulrich Herberg (UH): The OLSRv2-MIB is on hold currently until we get a reply from the IESG on the NHDP-MIB, but I will get into that when I present later. SR: I am working on moving packetbb-sec forward as well. I am not sure where we are with the Report MIB. UH: Bob will present that in more detail later, but there has been a major change in the document. Charlie Perkins (CP): I really want to move the DYMO draft forward. If anyone wants to help I certainly want to move this forward. I admit I haven't done any work in years. SR: I agree the Working Group is chartered to do a reactive and proactive routing protocol so we either have to move it forward or go back to the IESG and let them know we want to take it back. Thomas Clausen (TC): There were a few reviews about a year ago. If there is more effort being put into the document these reviews should be dug up. I think the DYMO document would benefit greatly from an "after Christmas" diet. There was a lot of stuff in there which I was unsure how to implement. I second the fact that we are on the hook for producing a reactive protocol. I think it is a big task at hand to bring it up to speed. CP: Before Christmas there is absolutely no possibility on getting a new draft. As for AODV being a Standards Track document, I don't know what updates regarding relating to the format RFC5444 would be needed. TC: RFC5444 has a good amount of flexibility but I don't think that it is a strong constraint for a WG protocol. JD: I don't think there are rules for using RFC5444, but I think it would be a very bad signal to not use RFC5444. It should be used. TC: I understand what Justin is saying but if I were doing an OLSRv3, I would be expressing it more of a protocol expression but I would decouple the specific exchange messages from the operation of a protocol. I do think that reactive and proactive protocols have different requirements and RFC5444 might be too chatty. SR: Speaking personally. I agree with what Thomas is saying that it isn't a requirement. I also agree with Justin is saying that it would be nice to include support for RFC5444. To take a saying: "we either need to do this or don't". As a Working Group co-chair I will be nagging people on whether we are going to do this or not. TC: The ROLL Working Group is working on a peer to peer reactive protocol that is derived from AODV that is going experimental [draft-dt-roll-p2p-rpl]. There is LOADng [draft-clausen-lln-loadng], derived from Gabriel Montenegro's [draft-daniel-6lowpan-load-adhoc-routing]. The question is do we want to bring that work into this Working Group. What I am saying is that the IETF seems to have energy to work on these things but the energy doesn't seem focused within this Working Group. OLSRv2 SR:We are ready for the first presentation. TC: For OLSRv2 at the last IETF we folded in the metrics work which was an independent spec before. Previously, there was a section and an appendix which was not finished, which are now completed. I also found about five typos which need updating. I see the AD's nodding their heads. I will update the draft and send it out. Adrian Farrel: You don't need to do that if it is inconvenient as it will most likely be updated in any case. Bob Cole: Reading the document, do the algorithms change how we select the minimcal connected dominating set given that we have a more flexible metric or is is the same algorithm? TC: In the Chicago presentation in August the details are in there. When you flood things you want to select relays to provide shortest hop paths (covery based) and metrics can be used as tie breakers. The MPR flooding is still the primary method. So SMF is able to leach off of OLSRv2 signaling and selection of CDS election, and don't know if the new signaling will affect SMF. Teco Boot: I think there are more issues with OLSRv2 than just typos. I would like to have a WG last call next IETF. TC: I can't fix any issues if I don't know about them. SR: There was an issue related to the willingness TLV but we discussed this and there is a resolution to this issue. There haven't been any issues on the mailing list on OLSRv2 so now is the time to get them posted to the list. TB: I am time constrained related to reading the document but my issue is minor compared to the inclusion of the metrics. So can we have a couple of months to go over the document and have a Last call in January. SR: I would rather not go through a couple of months to put off last call as the list has been quiet for quite some time. TC: I would recommend we have a last call and get a document out before Christmas. SR: If we have an edit that we have a fix related to the editorial nits and the willingness issue then we do a last call on that revision. TC: I talked to Chris Dearlove and he agreed with the fixes that Justin and I discussed and he most likely has updated the draft already. Ulrich Herberg: My issues have been addressed and I have had plenty of time to provide a detailed review Joe Macker: we should get OLSRv2 last called within a month SR: To answer your question Teco we will get the next version of the draft and then do a last call with a four week windows. UH: I would like to discuss the fix regarding the willingness tlv and what is it. There might be a problem if an OLSRv2 node and an SMF node are existing in the same domain. The suggested solution is to use the willingness tlv which is currently optional, if we make it mandatory even without a value, we could assure that nodes not receiving this tlv will ignore this message regarding MPR election and forwarding. TC: let me explain that Chris has sent me text relating to how to do this. If you have an OLSRv2 router or a device that runs NHDP it doesn't run OLSRv2 on all interfaces or SMF on all interfaces you have to be more clever. You have to specify which of your neighbors are OLSRv2 and which are SMF. We can simplify this by assuming that all interfaces are SMF interfaces or OLSRv2 interfaces but I don't think we want to do that. But Chris has already has text which addresses this issue. UH: You are correct it is more than just a 2 byte addition. TC: Yes but we have a fix already. MIB status BC: So at a high level we updated the NHDP-MIB and went through last call. There were no comments on the list other than Justin when we first re-released the document. SMF needs reviews in the security cons. section. The Report MIB was reduced in size, which I will talk about. And the OLSRv2-MIB is awaiting completion of the NHDP-MIB. UH: We didn't it want to go forward with the OLSRv2-MIB because the NHDP-MIB might be more work once it goes to the MIB doctors. TC: So I just want to go on record with something. I spoke with Dan on of the OPS AD. If the protocols experts think that the MIBs agree with the protocol specification in that they reflect the state of the protocol that it should go forward. So those of us who consider ourselves protocol experts should state that they do reflect the operation of the protocols. I think NHDP-MIB does this. BC: SMF-MIB needs a review on the Security section. In particular what is the impact on networks ability to support multicast for each mis-configured config object in the security section. On the REPORT-MIB we removed the statistical model and we simplified it even further by using AUGMENTs. So next week I will publish an updated revision. OLSRv2 mib waiting for NHDP mib to finish and because NHDP has been updated with AUGMENTS, there will be some updates to the OLSRv2 MIB to point to these changes in the NHDP mib. NHDP security UH: There isn't much to say about the security documents, but we have made good progress. There is a 07 revision of packetbb-sec; the only difference is the expiration date and an updated reference to OLSRv2. There is no major difference between version 5 and 6. We have moved one appendix into the body which was normative but this happened before the second last call occurred. It ended and Stan is moving it forward. SR: I actually have the documents to move it forward. Speak now or forever hold your piece. TC: While Tim Polk was Sec AD, my understanding that he was quite happy with this approach. I do not know, Adrian, if you have had a chance to talk with the security ADs regarding this approach. He is shaking his head no. What happens after hits the AD? Adrian: IETF last call. TC: So can we get a heads up to the security ADs? Adrian: good idea TB: Is there operation experience with this protocol. TC: Yes. TB: Is something published? TC: Yes, Teco. TB: Is there something you can point to? TC: Some of it I can but some I can not. TB: I would like to have something to look at regarding experience. SR: Are you saying that this should be held up because to wait for experience? TC: Maybe it will help the document. SR: Are you saying there should be an informational document on how to use this? because we have gone through the process we have done last call and it is ready to go. TB: NO I think we should move forward but I think we it is important to have operational experience with this document. SR: So we are going to move this forward and if someone wants to write and operational document on how to use this then I think that is something the wg could support but there has to be effort there. TC: This document describes a tlv structure for carrying keys. It does not specify how the keys are generated or verified or a host of other things. I do observe that this document is fundamentally a syntactical document. We have had security approaches for OLSR protocols for a decade I am not saying it is military grade or anything but this specification is just a container specification. UH: NHDP sec document has not be updated since last IETF. We are waiting for two reasons: I don't have the time; and waiting for packebb-sec to move forward so any issues which come up there could be addressed. TC: I just wanted to add as well that since we have had a change of sec ADs we should send them updates. This is another reason we haven't moved this forward yet. I would also encourage everyone who is interested in security to have a look at the NHDP-sec document and the approach. Teco? TB: After OLSRv2 DLEP SR: The current draft has expired. The next version of the draft based on comments on the list we will have there will be a credit mechanism similar to RFC5578. We will as support for ETX. Notion of metrics with a peer update instead of a specific neighbor. Better state transitions. Neighbor up can flow in both directions not just from the modem to the router. I don't have a specific ETA on the document yet but coming soon. There are implementations available commercially both on the radio end and the router end in source forge based on the 00 version of the draft. There is a modemlpa document [draft-ivancic-mobopts-modemlpa-00] which has quite a large amount of overlap we are working with them to address these. Jiazi Yi: The modem can be on one interface or multiple interfaces? SR: The modem can only be on one interface. That device exists with relation of a single interface. Jiazi Yi: DLEP takes care of bi-directional links how will this work and how will metrics work with routing protocols. SR: The document does not address how routers use these metrics. There are two issues: one how do you get the metrics to the router, this is what DLEP addresses; the secondary issue is what do you do with this data and this draft does not address this. The one implementation the metrics obtained are used for route cost calculations. Slot for Bob Cole (Radios, SatCom and Considerations) BC: I am a DLEP fan but more I have thought about it I have had more questions. I want to talk about two different models. There are two different models in this document radio subnets and satcom subnets. So I am not a satcom guy but my understanding is that the sat com is giving the routers something which looks like a switched Ethernet. That has implications relating to how neighbors are discovered. KenC: Just for clarification your terminal is a layer two device and not a layer 3 device. Yes? BC: Yes TB: There are other models other than the two you are presenting (paraphrased) BC: Yes there are more than two models I couldn't think of all of the model. I am just presenting these two (paraphrased). TB: As long as these are just examples. BC: I think we are defining IP over subnets but we haven't defined what subnet models we are using and that makes me a little bit nervous. It might not make you guys nervous but it makes me nervous. BC: Presenting radio model, I think this is the DLEP model. TB: The link metrics for the p2p links can be very different. For different nodes on the same carrier can be different data rates. It is important that DLEP supports per-node link metrics. BC: The link definition depends on the underlying subnet model. I could have a radio subnet model which is a direct hop and the meaning of link is more clear. In the satcom model what does the link up and link down mean? I think it means that I am connected to the satcom terminal but I am not sure. TB: The link up link down message relating to per neighbor not the layer two connection that is just a switch. BC & TB: (discuss link up link down) SR: Yes there are different subnet models. What we have done in DLEP is we have stayed away from the link up and link down and gone with nbr up or nbr down but from the perspective of the router what we need to know is who else is out there that we can connect to, whether it is one hop, two hops, or multiple routes it doesn't matter. BC: I don't understand what it means that to have a router to request more bandwidth to a multiple hop neighbor. SR: I agree with your perspective. The request is additional bandwidth to the neighbor which is 15 hops away that is an issue for the lower layers to deal with it. BC: As a consumer of radio consumer. I am very worried to have an undefined underlying radio layer which DLEP is built upon. I would like to define about 4 subnet models so we would understand what the DLEP messages mean with context to the defined subnets. CP: In the autoconf group we have a document which goes right to this issue of the idea of link up/link down nbr up/nbr down. So this might be an idea to resubmit this document into the MANET working group. That is one thing the second thing is the autoconf group spent years discussion on what link up link down means we might get more traction here but there is danger with trying to define this. BC: I am not sure we are the people to define what link up link down means but it makes me uncomfortable to leave it undefined. CP: Trying to define a what a link is, is about as fun as stubbing your toe. BC & CP: discuss defining subnets and links Sue Hares: So I would like to point back to a couple of bits of work. I did some presentations back at MILCOM I am not supposed to say. First I am going to do the abstract. The real question is where is the policy barrier? As CP pointed out you have to put separate where policy happens. Once you define this you can put bgp or anything else on top of that. So there is some previous work here which can be leveraged. MILCOM07. The second is if you are in the wireless space. Thomas has done a large amount of work also the sensor coms stuff. You have the truck guys driving around and the make and break and the fast hello pieces for mobility. If you are starting down the modeling reviving this work, netconf, auto define policy BC: Starting down this I need to understand what dlep requires to operate and I feel I need to understand the underlying subnet layers. JM: comments from jabber Emmanuel Bacelli: I wanted to agree with Sue and Charlie there has been quite some work on this both on academia and industry. Charlie pointed to autoconf work which we spent quite a lot of time on perhaps it is incomplete [draft-baccelli-multi-hop-wireless-communication]. Both the work Charlie points to and rfc5889 which ends defines a link as an undefined link. SR: I would like to jump in here you mention that sometimes things just go wrong. BC: So what happens in satcom model if a new terminal appears. SR: If a new terminal appears the radio network does some magic.. BC: And this magic is what is scaring me SR: The radio has some intelligence and does it's thing once it has an answer DLEP can then be used to transit this information to the router. That is why we abstracted the nbr at the router layer so that the underlying... EB: That magic isn't magic it is just layer 3. In once sense people were expecting a model but we didn't get to a model we didn't make assumptions about the underlying. So rfc5889 might not be such a bad thing. JM: comments were directed to the DLEP authors. TC: Thanks Sue for the compliments. We spent a lot of time in the autoconf wg spending time on trying to define these nebulous ideas and I think we should wait until we have nothing else to down. If we really want to go there I think that we should do it in a revived autoconf working group and not within the MANET wg. BC: Interface and protocols. There are issues I still have with management and how data framing will work in with DLEP. JM: I think we should keep autoconf topics out of this working group. CP: I don't think there is any way to have a solid subnet model either you have a specific model or you don't assume any model. You have just so much trouble trying to present the model to layer 3. SR: That is what we did with DLEP we punted. At the physical layer it gets really complicated really fast. For the framing its transparent to the router. BC: How do I get information into the interface SR: Current it is an Ethernet device in implementations. BC: The draft mentions USB or other. SR: Current implementations use Ethernet BC: So if we were to do that diffserv and other methods are not supported and are we just going to drop it. SR: TB: The metrics exchange like dlep but I am not sure about flow control and credits? SR: I am on the hook for adding PPoE style credits into DLEP draft. TB: I think we need the general model on how the router and the radio what is the channel. Justin Dean: I don't think we need to specify a single data connection between SMF status discussion (notes taken by Emmanuel Baccelli) JD: do we push to use ID field or not (based on intarea doc)? Charlie: is this intarea doc going for experimental or standards track? JD: it's aiming for proposed standards, not yet RFC. I'd be in favor of keeping it in. What does the wg thinks about it? Thomas Clausen: We could get rid of IPv4 and just go for IPv6? What does the IESG think about it? Farrell: The IESG is a weird beast. It's not predictable what they would think about this. Lots of different opinions. Send a message to the IESG to test reaction? Teco: it's helpful to use it, it's doing no harm. Stan: the use of ID field in IPv4 bothers me, it's overloading a field. It can get messy. Farrell: I must admit I also hate overloading a field. Teco: Could we use fragment ID to do duplicate detection? Macker: my intention is to take it out, we can manage without it. The fragment ID is already used. Teco: are we overloading this field, then? Should we take it out? My proposal is to use the ID field when it is useful. Let's ask the IESG about it. Ulrich: we should take it out. It's overloaded use is risky. Thomas: it's a feature for IPv4, not a bug. It's a transitional mechanism. In IPv6 we already got a mechanism for this ok. Stan: let's take it to the list