Mobile Ad hoc Networks (MANET) Minutes Meeting : IETF 84 Monday July 30, 2012 Time : 1300-1500 Afternoon Session I Location : Regency A Chairs : Joseph Macker Stan Ratliff Secretary : Ulrich Herberg 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/ ========================================================= 1) Agenda Bashing - Stan Ratliff Agenda was approved. 2) Working Group Status - Stan Ratliff OLSRv2 in IETF LC NHDP-MIB in AD review; Robert Cole: The authors believe that all issues from IESG evaluation have been addressed, but Thomas Nadeau has not confirmed yet whether this was to his satisfaction. Adrian: Eventually, the issues have to be escalated to the AD who has the DISCUSS (Benoit Claise). The document will be on the IESG telechat after the IETF84 with an ultimatum on Benoit. 3) Milestones Update - Joseph Macker Posted milestone items are out of date. WG chair updated some basic milestones (see slides) Thomas Clausen: What about other WG drafts, like NHDP-sec, NHDP-sec-threats? Joseph Macker: All documents should be included on the milestones, so any info from the authors on dates for these would be good. Please suggest dates on the working group list. Adrian Farrell: Charter page already updated with new milestones. Don't necessarily need to have milestones for each document. Milestones are a tool to assess working group progress. Joseph Macker: Dates for documents would still be good to have for guidance. 4) OLSRv2 Update - Thomas Clausen History of OLSR/OLSRv2 drafts Got review from Adrian cojoined with IETF LC. Changes from revision -14 to -15 only very minor. Adrian's comments: - Suggested to add text not to obsolete RFC3626: OK - Questioned use of using capital "MAY" in section 2 that anycast addresses MAY be routable addresses: We suggest to remove RFC2119 language - Concerned about RFC2119 language used in appendix D. Answer from us: this is exactly done like in RFC6130. This is done because it lists constraints how *other* external processes wanting to update information bases of OLSRv2. - Concerned about Flow and Congestion Control appendix; whether it should be appendix or in the main part. Since it is not prescriptive, we agreed to leave it as appendix. We will update the document after getting comments in IETF LC. 5) OLSRv2 Metrics Rationale - Thomas Clausen Changed the document from *how* to use metrics in OLSRv2 to what is the rationale for these decisions. Document was accepted as an informational working group document after polling attendees. There were no objections. Joseph Macker: Are there other people that would want to present similar documents on other metrics (e.g. ETX)? Thomas Clausen: This document does not prescribe specific metrics, but more a of a high level "howto" and rationale for outbound vs. inbound metrics, etc. A document describing how a specific metric type should be applied would be _complementary_ to this document (i.e. such as an ETX spec) Henning: I have been working on an ETX document for some time, but sidetracked whether this is the only way or not. At the moment, that discussion has not been resolved and not sure how to move forward for the moment. Jabber Message (Rick Taylor): need for link metrics discussion on the list with respect to DLEP. Stan Ratliff: Yes, a discussion is needed, but DLEP is just a transport for such information. Henning: DLEP is a good tool for having better metrics without handling raw data. Most metrics need data from the radio and if we have DLEP, we will have the means for specifying and getting such data from the radio. 6) LOADng - Thomas Clausen Presentation of LOADng, a reactive on-demand routing protocol, using RFC5444, lean and small core document, intended for Proposed Standard Compared to AODV: no intermediate RREP (no gratuitous RREPs), no precursor list, hooks for optimized flooding, extended use of routing metrics Several companion documents written by Charles Perkins (precursor list, iRREP) Multiple deployments of several thousands of routers, 6 known implementations, interop reports (3 interop events), MIB If LOADng comes along as WG document for the reactive routing protocol, we would like to also propose the LOADng interop report as Informational document JP Vasseur: What is the use case for LOADng? Thomas Clausen: Many use cases. Reactive protocol, there is enormous body of work comparing reactive vs proactive protocols. Advantage for proactive protocols are that you have global topology, and can therefore do traffic engineering etc. Advantage for reactive protocol is that there is no need to maintain a full topology. JP Vasseur: Specifically, what are the use cases of LOADng that AODV cannot address, and for wich you need LOADng? Thomas Clausen: MANET charter requests to standardize proposed standard reactive routing protocol. JP Vasseur: IESG chartered ROLL to come up with one routing protocol for LLNs. We came up with requirements and with one routing protocol addressing these requirements. LOADng seems to address the same requirements as LLNs. Thomas Clausen: LLNs is one of the applications of LOADng, but by far not the only one. LOADng would run very well in an LLN. JP Vasseur: We have a routing protocol for LLNs [RPL]. What is the motivation for coming up with yet another one? Thomas Clausen: Because MANET charter stipulates to standardize a reactive routing protocol for MANETs. Proactive vs. reactive routing protocols is very well studied domain. Joseph Macker: The draft mentions a lot LLNs in the introduction. What are the use cases for MANET beyond LLN? We have to be specific about it. That is the valid comment being raised. If this is to be a MANET document, it has to be more general. JP Vasseur: Why is a second protocol for LLN protocol needed? Thomas Clausen: draft-clausen-lln-rpl-experiences describes why I believe RPL does not fulfill the needs for LLNs. We should have that discussion in the ROLL meeting JP Vasseur: Why don't we wait for a decision until we discussed that in the ROLL meeting? Thomas Clausen: This protocol is motivated in MANET working group, which is chartered to produce a reactive protocol JP Vasseur: I think we already have one, AODV, no? Thomas Clausen: AODV is experimental, LOADng is intended to be proposed standard. JP Vasseur: So why don't you make AODV proposed standard then? Thomas Clausen: When you update a document, you take the experience acquired over the years and fold it into the document. This is what is happening here. Yes, I do believe that RPL is not a good protocol but that is out of scope here. LOADng, AODV, DSR etc. are protocols that each have certain applicabilities; we have experience that LOADng has applicability in MANETs, some of which applicabilities you may call LLNs. But the motivation for developing LOADng was that MANET is chartered for a std. track reactive protocol. Stan Ratliff: There are some questions about overall use cases and potential overlap with ROLL or other working groups. It goes back to the question as adoption as a proposed standard in this IETF. My desire as a working group participant and co-chair, I do not think we should accept this as a WG document at _this_ IETF until some issues are resolved. Joseph Macker: MANET was chartered to develop both a proactive and reactive protocol because MANET scenarios were identified where reactive protocols work better. More modern chartered MANET protocols will need to address heterogeneity, gateway issues, better IPv6 use, and interoperation with infrastructure network. Justin Dean: Engineering choices (PacketBB use, etc) in LOADng differentiate it from the original AODV spec and can improve AODV. Stan Ratliff: I don't think it's ready yet until some issues are addressed. Thomas Clausen: We need to know what these issues are. Does MANET question that we work on a reactive protocol? Or do we question the scope, which I think is not a big issue. TC: are we not adopting a reactive protocol or are we just talking about word-smithing the document? Stan Ratliff: Are we proceeding forward with LAODng or DYMO or both and there needs to be discussion on this? TC: Its my understand that LOADng has the momentum of everyone interested in reactive protocols, and DYMO has been shelved. Brian Adamson: Joseph made a point relating to more general MANET use case, such as heterogeneity and gateway management. Is this document doing this? TC: Yes for heterogeneity (stems from use of metrics) and for gateway management that is in a companion document which is being worked on right now. If it is adopted as a working group document it can be discussed if it should be part of it. JP Vasseur: You mentioned that one of the use cases could be LLN. TC: One of the use cases *is* LLN. We have running deployments of LOADng in what you call LLNs, and what I call MANET. JP: If that is the case, should we ask the IESG what they think? They asked us to have one protocol for LLNs. Stan Ratliff: What is our AD's opinion for that? Joseph Macker: We are chartered within MANET to do a reactive protocol, but while it may be applicable in LLN, it is not specific to LLN. Thomas Clausen: Many of the authors come out of experience in MANETs with LLN characteristics. Adrian Farrell: If you were to pick up a reactive protocol for MANET, you would be in charter. If you pick up a protocol and your main use case is for LLNs, you have diverged from charter. Main use case is delicate thing to talk about. It is clear that some if not all LLNs are MANET. Not all MANETs are LLNs. So you need to be producing a single reactive protocol for MANETs, not for *some* MANETs. You need to be clear that the protocol you work on is applicable across all MANETs. If that picks up some LLNs across the way, no big deal, but it should not be main use case. Look at all use cases for MANETs and make sure you address all of those. Act of caution: To accept LOADng, is to stop DYMO progression. Thomas Clausen: LOADng is doing what you say. General reactive protocol for MANETs (which happens to include LLNs). Joseph Macker: Document currently reads a little LLN heavy. Charlie Perkins: We can make a single reactive protocol. LOADng has the same roots as DYMO. But with LOADng there is a better solution. Should be able to meet the needs of the LOAD community and general reactive community as well. It is easy to imagine it as a good publication for a reactive protocol. JP Vasseur: We have a report that show that LOADng does not apply to LLN. If you were to say that LOADng is applicable for everything except LLN, then I am fine. Thomas Clausen: I know of deployments of several thousands of nodes running LOADng (I know of one deployment with 8000 nodes). Don't think you can say that LOADng is applicable for everything except LLN, when (as Adrian said) all LLNs are MANETs. As we know from the past, it is always possible to come up with a scenario where any particular protocol does not work. JP Vasseur: Will share report with you and the working group. If you can show an 8000 node network with LOADng, I would be quiet. Thomas Clausen: We have a protocol with about 8 companies that have built and deployed this. Does the IETF want to standardize IP protocols that people are using or let the ITU, etc do that? Stan Ratliff: We are trying to stay within our charter. Joseph Macker: We want commitment from the authors to work on the scope, fitting it into the charter. JP Vasseur: I have seen T. Clausen's presentation at the ITU? Thomas Clausen: I have not set foot within the ITU. Charlie Perkins: I think we can go forward and this can be a good resolution, but not instantly. Ulrich Herberg: Need to update the draft to make the use cases more specific, etc. Thinks it's important. Joseph Macker: I think we have commitment to move forward here. Take these comments to heart and keep going. Teco Boot: Please put "manet" in the title. E.g. "draft-clausen-manet-loadng …" instead of "draft-clausen-lln-loadng …" LOADng-MIB - Ulrich Herberg JP Vasseur: Are you planning to implement a MIB in a 4-bit MTU? Ulrich Herberg: Need to provide a management interface. Thomas Clausen: JP said if you want to have a MIB, you can't use it for LLN … LOADng is for a large set of use cases. For some you may want to have a MIB. For others you may not want (or be able to) have a MIB … and that is OK DLEP - Stan Ratliff Henning: Core spec and extensions stack makes it easier to say what the device supports. Makes it clearer to see which features are supported instead of core document with a bunch of options included. Radio and routers are produced by different companies and they must work together, so this all needs to be very clear. Rick Taylor (Jabber): a minimum set of core features must be in the spec and clearly defined. Teco Boot: We have a good record of taking a long time to produce standards. Nothing prevents us from producing an experimental protocol from what's on the table right now and perhaps the next version becoming standards track much the same as the other working group protocols. Joseph Macker: I don't think we can afford to wait Henning: I think we can work and get the DLEP "core" done in a short amount of time. Radios are built right now and we can't afford to spend years going back and forth with this. Brian Adamson: I agree with Henning. I think it's appropriate to build a core but I also think it should specify how its appropriate to extend DLEP. Joseph M: An information document which we presented before which gives the reasons for a protocol like DLEP. Brian Adamson: My point of view is that some people don't see what DLEP is capable of. (I.e, think it doesn't do everything that existing protocols (e.g. PPPoE, R2CP), do. Henning: There are protocols that attempt to do a similar job, but we can work with the experience and do a better job with DLEP. Rick Taylor: A document was proposed but did not get accepted. Joseph Macker: Proposed document was more of a requirements document and not providing the motivation / rationale that an informational document could ... Rick Taylor: Producing another similar document seems like pursuing a red herring. Joseph Macker: Do we put an applicability statement in or need an informational document. Stan Ratliff: We can provide added information, applicability, etc to get the spec moving … Thomas Clausen: Stan explained what it can be used for and Stan said we could do that. An added informational document may not be necessary but some educational text in the DLEP document would be helpful. Stan Ratliff: We tried to do that in the document so I suppose we will have to revisit. Brian Adamson: One of the things we did in the SMF document was with the appendix section which provided a template of sorts for expanding the base specification. I know that it would require some reorganization of the DLEP specification . Henning: Most radio engineers are new to the router area, concepts and explaining to them the DLEP motivation might help. Stan Ratliff: Adding motivation to DLEP is OK and we need to work out what that is. Rick Taylor: Another document would slow down progress on DLEP and we would like to see this progress quickly. NHDP MIB - Bob Cole Bob: Lot of discussion with IESG about NHDP-MIB. We try to drive the organization for the following MIBs (OLSRv2/SMF/REPORT-MIB). New revision of NHDP-MIB that addressed comments from MIB-doctors and IESG. Multiple folks asked about use cases for management. Agreement with IESG was to put in an applicability statement in, which we did. The agreement also was that they wanted a bigger discussion of use cases for management in MANETs, and asked for an informational draft that has to be published. Bob: Added many things, DEFAULT objects, UNITs etc. Removed some notifications that were deemed harmful (e.g. tracking bad packets). Bigger isue: We have an NHDP ifTable, which was not scoped; duplicates from IF-MIB. Suggestion from MIB doctors was to run on "MANET" interfaces only, not on all interfaces (by requesting a MANET ifType by IANA). Only way to define this ifType is an interface that runs a MANET control protocol. Teco Boot: It's a configuration of the protocol as far as to which interfaces are applicable. Bob Cole: You can configure via the ifTable which interfaces are "manet" interfaces. MIB doctors wanted to avoid populating the table with all interfaces. Ulrich Herberg: This was only requested by the MIB doctors for scalability reasons. We don't want to redefine what a "MANET interface" is; this is only used inside the MIB module. Stan Ratliff: Since this is the NHDP MIB, why isn't the interface a "nhdp" interface type? Bob Cole: We would have to define "nhdp", "olsr", "smf", etc ifTypes then. OSPF doesn't address (to answer Joseph Macker's comment on that) Justin Dean: NHDP can advertise interfaces are not running "manet" protocols … Joseph Macker: OSPF has different interface types (broadcast, mnba, etc) MANET has a collection of interface types. Bob Cole: So proposal is to define a general "manet" interface type for this Teco Boot: Still confused … Bob Cole: Can define over wireless and or other (example Ethernet) interfaces. Teco Boot: Is the intention here that this is a manet interface? Bob Cole: This mechanism lets you define which interfaces are applicable to manet for management purposes? Thomas Clausen: Have some deployments of OLSRv2 that run over layer 2 … disabling the need to run NHDP. Is that deployment not a MANET? Joseph Macker: This doesn't appear "right" as compared to how OSPF does things ... Adrian Farrell: "This is broken and a pile of doodoo". The interface type is a description not a prescription as to which protocol to run. Bob Cole: I don't know what was broken with the original document. Adrian: We can talk to Tom Nadeau (his comment) about this this week. Joseph Macker: Please see the OSPF MIB. It appears to make sense in this area. Thomas Clausen: Do we need to justify why we need a MIB for each and every protocol? Ulrich Herberg: We were asked to provide such a document. NHDP Security - Ulrich Herberg Thomas Clausen - packet level ICVs are just as good/bad as Layer 2 security since different messages are handed off to different processes. Ulrich Herberg: WGLC for this? ECDS-MIB James Nguyen Justin Dean: The appendix to SMF has multiple algorithms, but the Router Priority was common to the different algorithms. If it is just that, then it should support the common objects across the SMF.