Session Date/Time: 17 Mar 2026 08:00
Don Fedyk: All right. I have 4 a.m. my time, so that means it's 4 p.m. in Shenzhen. Welcome to the MANET work group. We have our three chairs online: Ronald in't Velt, Donald Eastlake, and myself, Don Fedyk. This session is being recorded.
And I'd like to point out the Note Well. You should all be familiar with this, but if it's your first time, you agree to these the IETF process and these policies. And it's a reminder: this slide and the actual text for this version is in the references here, and it outlines the conduct and contributions and the detailed process, etc. So please take note.
This session is being recorded. So meeting tips for anybody that's in the room: please sign into the data tracker to see your attendance will be recorded. Use the Meetecho Light tool to join the queue or show hands, and keep your audio off if it's not-- if you're not using the onsite version. Remote participants: make sure your audio and video are off unless you're chairing. Use a headset, please. All participants, state your name each time you begin speaking at the queue.
These are the resources for MANET in Shenzhen. We have the agenda, these slides, the meeting information. And if you need any technical assistance, please see the meeting issues.
Resources for this work group session. Again, there's a bunch of hyperlinks here, so the materials in PDF, etc., the chat and the audio. If we could get somebody to take notes, that would be great. I don't know how well the transcription is working, and I've seen on some meetings where there's been some dropouts, so any notes would be appreciated.
So the agenda today, we have the chairs' administrivia, and again, note-takers. We'll go through the document status. And then we have a presentation from Fred Templin on the two drafts. He has the draft-templin-manet-inet-gaps and draft-templin-manet-inet-omni. And then we have a short presentation on the responsive use of MANET by Christopher Dearlove. And then we have any discussion and wrap-up in the chairs-- by the chairs.
So document status. Do you want me to talk through these or do you want to say anything, Ronald?
Ronald in't Velt: Um, what I would want to say as a former document shepherd for these-- these documents is that I would want to thank everybody involved for their patience and perseverance. It was a long road to finally get these things published, but I want to say thank you to-- I have to say the surviving authors, unfortunately. Our AD, all the reviewers, and the people from the RFC production center, who've been very good in ironing out the last few issues. So thanks.
Don Fedyk: Thank you.
Ronald in't Velt: Oh, and one other thing: I hope to see some implementations of this at one day, and will try to work on that myself.
Don Fedyk: Yeah, I-- I am aware that some of these aspects are being worked on. I've seen-- I've seen some implementation of them.
Um, and we have three active drafts, three short drafts: the draft-ietf-manet-dlep-channel-utilization, the draft-ietf-manet-dlep-radio-band, and draft-ietf-manet-dlep-radio-quality. They've gone through the last call. They've just been updated, so please have a look and-- and make sure that if there's no more comments. I'm going to issue an IPR call for each draft because I didn't see any record of that. It's just to formally make sure that we have a record of that.
Some comments are still being addressed. I don't know if you've had a chance, Ronald, to look at the latest ones to see if the comments-- your comments have been addressed. Um, but if they have or have not, please resolve that on the mailing list. And we'll proceed to submitting them to the IESG after the IPR calls and-- well, and any comments are addressed. So in the next few weeks, we should be able to close on those. Anything else you want to say, Ronald, on these?
Ronald in't Velt: Uh, no, I did not have a chance to look at the latest versions because I understand Henning posted those this morning. Um, but I will. I will.
Don Fedyk: Okay. Okay.
And the related individual drafts: we've got the draft-templin-manet-inet, which is the gaps draft, I believe, that talks about MANET routing between MANETs and talks about the situation and any gaps that are there. And then a proposal draft on Omni. These are still individual drafts. We'll have some discussion of that and they're going to be presented this session. Please, if you have any comments, review these drafts and make sure that if you have any-- any comments, take that to the list.
And then we have the draft-dearlove-manet-olsrv2-responsive. We're going to have a brief presentation on that today. And we have a draft-perkins-manet-aodvv2, which talks about implementation status that's been presented at IETF 123. Um, another one: for all these drafts, please review and comment on the mailing list.
Um, and not materialized yet. Um, Ronald, this is your slide. Do you want to talk to this?
Ronald in't Velt: Uh, yes. Um, so at IETF 124, the Montreal meeting, I sort of announced that there was this work on the horizon. Um, and yeah, with I was then hoping that we would have an initial draft for this MANET Awareness Model, which is basically a YANG model that gathers information for instance from DLEP, but also from whatever routing protocol you're running on a MANET router and makes this-- this information available to-- to hosts, for instance, who can then, for instance, adapt their-- the traffic they will be sending to the status of the network. Um, apparently this is taking a bit longer, so we're hoping to have a draft now in-- before the next meeting.
And then I presented-- I re-presented some older presentation on issues that have been discovered with the basic DLEP document, RFC 8175. Um, and we had some discussion on whether we should do an update document for 8175 or do a complete 8175bis document. Um, and we did a poll at the Montreal meeting to see who was interested on working on this, and unfortunately, I was the only one who raised my hand. And then I said, okay, then it's going to be a slow process, and that turns out to be true. So it could be a while before I will be able to share something on that with the group. That's it.
Don Fedyk: Okay. So that's it for the chairs' slides. If we could bring up-- Fred, is Fred online? Do we have Fred?
Fred Templin: I'm here, yes.
Don Fedyk: Okay. Could we bring up Fred's deck?
Fred Templin: Okay. Do I have control now? Okay. All right. Um, this is a presentation about MANET internetworking, and you can see the drafts there that are in question in this presentation. I'm going to be jointly sharing this presentation with Dr. Daniel Jacobyson, who's also online right now, so we'll be switching over midway between the talk and we'll each give our portions of the talk.
So a little bit of MANET background. Um, MANET concerns a multihop communications capability between often low-end mobile nodes operating in a common multi-access packet radio medium within the coverage range locality. Community interest in MANET began in the late 20th century with programs like DARPA Packet Radio, Army Task Force 21, DARPA GLOMO, and others. Um, then in the late 1990s and early 2000s, there was intense work on the first MANET optimized routing protocols in the IETF, and it produced two proactive protocols, OLSR and TBRPF, and two reactive protocols, AODV and DSR.
So beginning in year 2000, I contributed to the TBRPF RFC and also was the lead author on the ISATAP RFC, which ISATAP is a non-broadcast multiple access virtual interface type for V6 overlays. So at that time, we took the TBRPF protocol and ISATAP protocol and flew them on Yamaha RMAX helicopters as some of the very first MANET internetworking vehicular communications demonstrations. Since those early years, IETF has since developed other MANET routing protocols, and what we want to look at now is called MANET internetworking, which is routing protocol agnostic and it seeks to bridge disjoint local MANET clouds over the internet as an overlay over the internet. So I'd like to now turn over to my co-presenter Dr. Daniel Jacobyson, who's going to be handling the next charts. Can we get the chart deck over to him?
Daniel Jacobyson: Hello, everyone. Can you hear me?
Ronald in't Velt: We hear you.
Don Fedyk: Yeah.
Daniel Jacobyson: Great. Okay. Looks like I have control of the slide deck here. Yeah. Okay. Thank you, everyone, and wanted to start with a first slide here that is a slide that I used in-- in the previous Montreal presentation to kind of just level set on this particular use case. So I presented a few use cases last time, want to focus in on this particular use case of the UAV swarm. And as you've seen kind of illustrated in this slide, what Fred was just discussing, the idea that you could have a couple of local MANETs with local routing, and perhaps there is a means to have MANET-to-MANET interconnection, but we might find it more efficient and more reliable to route and form inter-MANET connections through this overlay that also utilizes the internet as a backbone.
And so, as an alternative to-- I can't count quickly here, maybe five hops I've shown on this slide and having to successfully achieve communications across those five hops, we might instead use an interconnection with a base station, which provides access then to the internet on the left-hand side, and then interconnects with this MANET in another location closer to the end destination. And so the ability to have support for protocols that allow for this interconnection to happen seamlessly are of interest.
And there's a number of scenarios then that we've been thinking about that motivate some of the discussion today, and I'm going to step through a couple of those, a couple of illustrations that give some kind of pictorial example of what this might look like. But overall, looking for the ability to robustly handle mobility and topology changes because in the UAV swarm context in particular, we expect these networks to be highly dynamic, and not just move, not just have mobility changes, but also MANETs that may be originally just supporting local routing may encounter each other.
So here's an example of we have two local regions initially, and so MANET routing is taking place within those local regions. There is potentially also interconnect to external networks to potentially reach the internet as a backbone from these. So in the left-hand example here, there's an interconnect with a base station, and the right-hand example, a non-terrestrial network (NTN) interconnect. And the objective here would be to establish MANET local routing and border gateway protocols such that dynamic MANET-to-MANET routing or MANET-to-internetworking would be supported.
And if we just flip through the illustration here, the next slide here shows, okay, the MANET on the left has shifted. We now have the possibility for interconnection. So one of these MANET nodes that was previously just a typical device in the network potentially could be elevated to serve a gateway purpose. And in this case, we would want to make sure that we propagate host routes that existed within these local regions across the new interconnection and make sure that they are available and discovered as a result of this new interconnection.
In addition, if the base station and the non-terrestrial network satellite both provide internet interconnection, that can again provide a means of routing between the two MANETs, as I kind of showed in that first slide. And then finally, if these MANETs continue to persist in the same area, then we would be interested in a local region merger, and so to have protocols that seamlessly support the merger of local MANET regions into a larger region would also be of interest. And again, if interconnection through the internet provides more reliable service across the MANET, perhaps that's still a route that's used. But the ability to kind of step through these different scenarios in a seamless way is part of the focus of what now Fred's going to walk through kind of from a technical solutions standpoint. So this was just to set some motivation and some scenarios that would use these types of protocol modifications. Fred, back to you.
Fred Templin: Okay. Thank you. Can I get slide control back again? Thank you.
So now this subject of MANET internetworking. Although we're presenting this as if it's kind of a new idea or new subject, it really got started 26 years ago when we had those first experiments with TBRPF and ISATAP in the helicopters that we were flying at those times. So this has been developing for the past 26 years. So the idea is that the global internet's going to provide transit overlay bridging between distinct MANET local routing regions. You can see the diagram: you have MANET 1 on the left, MANET 2 on the right, and the internet as a-- as a transit network that bridges the two clouds over an overlay over the internet.
So the MANET routers are going to assign multilink local addresses (MLAs) to an overlay multilink network interface, an OMNI interface. These addresses are locally routable in the MANET local routing regions, and they're also globally routable over the OMNI link limited domain, which is again, a virtual overlay over the internet. And that means that the MLAs must be assured globally unique because you can never tell which two MANETs are going to be joined over the internet at any given point in time.
So for the MLA, the address choice that we're using for that is RFC 9374 IPv6 addresses which include security registry information in the routing prefix and a cryptographic interface identifier. So this provides not only assured unique, but also cryptographically oriented addresses that can be used to authenticate nodes that are authorized to use the addresses.
So for MLA routing in the MANET local routing regions, the MANET routers run a MANET routing protocol to exchange MLA host routes, like IPv6/128s, for multihop forwarding in the local routing region. The MLA host routes in the MANET local routing region A are mutually exclusive for those in local routing region B. But as Daniel's charts showed, if regions A and B ever merge, both become aware of the union of all MLA host routes and now combined larger local routing region.
But we can also use clustering internally within the merged local routing regions to limit the extent of MLA host route propagation. So the idea is that you want to have as few routes as possible in your MANET local routing region, but you want to be able to address as many nodes as possible, and that's-- this is where the-- the clustering can come into play.
So the MLAs in the OMNI link virtual overlay. The OMNI link virtual overlay provides a bridging service to connect disjoint MANET local routing regions over the global internet, as we saw in the earlier diagrams and use cases. The overlay must support routing between MLAs in the local routing region A and those in local routing region B for all regions A and B that connect to the OMNI link. What that means is that the MLA host routes must be propagated over the OMNI link virtual overlay interdomain routing protocol. And for the overlay interdomain routing protocol, we're using BGP to propagate host routes. The result is we have a MANET of MANETs with BGP as a MANET routing protocol, which is maybe surprising to some people. BGP scaling limits suggest that this could scale to maybe 10^6 or 10^7 routes. But what would happen if we needed to scale to larger than that still, say, on the order of the scale of the number of nodes in the internet?
So for OMNI link virtual overlay scaling, the OMNI link may join very large numbers of disjoint MANET local routing regions, again, on the order of the scale of the internet itself. The BGP interdomain routing service alone would be challenged to deal with so many MLA host routes, plus the degree of mobility-related churn, which would be too much for BGP to carry. So we're looking at the possibility of having BGP interdomain service augmented with a DNS next-hop resolution lookup capability that can address the scaling limitations both in terms of the numbers of host routes and the mobility churn. In other words, you get an address that you don't have a route for, you look in the DNS. If you find the DNS has a server address associated with the address in question, the reverse DNS as such, then you can go to that server and find out where the host is located.
Next steps: we want to ask for adoption of the three drafts that you see listed here. The first draft, as was said earlier by the chairs, is the problem statement and gap analysis draft, draft-templin-manet-inet-gaps. The second draft is the draft-templin-manet-inet-omni, which is assuming the OMNI and AERO solutions as solution proposals. And the third is the draft that specifies the MANET local multilink local address format. And that's where I'll stop. I think I've got a backup chart, but that's-- that's all I wanted to present for today. Can we have some discussion about these next steps?
Ronald in't Velt: Uh, yes. Thank you, Fred, for the presentation. Um, yeah. With regard to the first draft, I would like to see a few more reviews and comments on the mailing list, but then, yeah, I think we could at some point adopt it as a working group item if there's agreement that there is a problem to solve there and there is a gap that we should address.
Um, with regard to the other two drafts, I think we first have to take a close look again at our current charter to see whether we can actually work on those. And especially the last of these three has a sixman marking. Um, so would that one have to be adopted by sixman? I wonder.
Fred Templin: I'll just offer that we could change that-- that designation to MANET if there's interest to have it come into the MANET domain.
Ronald in't Velt: Okay. Yeah. But we would have to at least coordinate with sixman then, I would think. Um, so I don't know how closely you followed this, but we had some discussions about rechartering and what would be in scope of the new charter. And our Area Director said last year at the IETF 123 at the Madrid meeting that he was not going to let us recharter because he felt that there was not enough activity in the group for the moment to go to the whole process of rechartering, which he found to be quite a burden on himself and the rest of the IESG. Um, so we would first have to prove that there was still some energy left in the group, and then we could discuss rechartering. So we would have to discuss with him whether anything beyond the requirements and the gap analysis draft would be something we could work on.
But let's start with the draft-templin-manet-inet-gaps and see if we can get that adopted as a working group item. And in the meantime, we will talk to Jim Guichard about what to do with the other two and if we can get them in scope. That's my opinion, but maybe one of my co-chairs or anyone in the audience has a different view on this.
Don Fedyk: Yeah. Um, so I'm in the queue, so I'll speak now. Um, so I read through this draft and I thank you for the draft. Um, and I think it's definitely a, you know, a good start. I didn't know if it was the only solution, and I think-- I think the draft could do pointing out some other solutions and the, you know, the pros and cons, the drawbacks. I have to admit I used the AI and I asked it that question and it did point out like three models. Your model, OMNI, was one of them. The Host Identity Protocol as a another attempt that had been made to connect MANETs was another one. LISP, which I did-- we've talked about this briefly before. Um, LISP takes a different tact, slightly, of solving-- could be applied to solving the problem. And then there is a number of other, you know, it pointed out another number of other possibilities that, you know, workarounds that don't-- don't work today, but they've been applied in the past such as NAT and tunnels and VPN overlays, etc. Um, so I think rounding out the gap analysis to at least mention, you know, some of the historical, if you've got that information, the other types of things that didn't get really wide adoption in the past and, you know, why you think OMNI, the attributes that it has, I think that would be beneficial all around to completing the draft.
Fred Templin: Okay. Thank you.
Christopher Dearlove: Yes. I confess to not having read the draft. I can say that we were looking at scenarios like this, I'm not quite sure when, sort of the same order of 20-odd years ago, and it was one of the motivations for the changes between OLSR and OLSRv2 was that to support the internal MANET side of that. But we never, of course, approached the either the how the external world feeds that information into the required gateway things. The gateway messages are there, you have to feed them, or pulling the information back out. We experimented with using OLSR as an overlay network for OLSR. Um, but that's not a sensible suggestion and the scaling that Fred mentioned would make that impractical. But yes. So yes, it's definitely an requirement that people have looked at for many years. Whether this is the right solution, I confess to not having read the draft.
Fred Templin: Thank you.
Ronald in't Velt: Ronald, you're on mute.
Ronald in't Velt: Thank you. Um, so I put myself in the queue with a more technical question. You mentioned BGP. I also confess to not having read the OMNI draft. Um, but BGP operates on AS numbers. So is a MANET an AS in that regard?
Fred Templin: So if you're familiar with the 5G terminology, you've heard the term GNodeB before. The GNodeB is the gateway for 5G. That GNodeB would have an autonomous system number. And the GNodeB would have the list of all MLAs, the list of all host routes that are associated with MANETs that attached to that GNodeB. And then the GNodeB would connect to a BGP gateway and use its autonomous system to then inject its host routes into the interdomain BGP. So that's where the autonomous system comes into play, at the GNodeB.
Ronald in't Velt: Okay. Okay. But what if, say, a MANET has two entrance points or exit points, two gateways to the outside world? And then at some point, the MANET gets segmented with one of the gateways remaining in each of the segments? Then you have a sort of a dynamic extra MANET thing. We looked into something similar and then we came to the conclusion that we should have some equivalent of AS numbers that was dynamic, if you understand what I'm saying.
Fred Templin: I do understand what you're saying and that's not something I've really thought about in that much detail yet. But if you did have multiple gateways that left the MANET, each of the gateways would have their own autonomous system number and they would represent the MLA host routes that have affiliated themselves with those gateways. So if you had a segmentation, then you would have to stop advertising some of the host routes that are no longer in the partition that you've been segmented away from.
Ronald in't Velt: Okay. Um, I will look at that and ask further questions on the mailing list. Thank you.
Fred Templin: Thank you.
Abdussalam: Yes. Do you hear me? Hello.
Fred Templin: Yes.
Abdussalam: Yes. Abdussalam Baryun, Techana company. I'm interested in these drafts and I think they are important for this working group. Actually, our working group has been for long not having discussed these problems which I thank Fred very much, he outlined it and discussed it very well. And we need to make more discussions in this working group. So I hope also that our working group chairs read the documents and comment on it. If we have now these drafts and we don't get comments from the working group chairs, then why we should have a working group from the beginning? It's not-- I didn't expect that from our working group chairs. And also, I will hope that the authors of these documents to bring two or three other interesting from their country. You know, if I have a draft but I don't have any discussions, I need to bring colleagues from the same city or same field, other companies. We have to do some work on this. Otherwise, then why we have a working group then? So I hope that we work on these challenges of these three drafts. Actually, before, they were working on this MANET working group was working on the routing protocols only. They don't go for the internetworking for MANET. And MANET should be the main problem or the challenge they should discuss is these three drafts, or the drafts which are mainly on the networking, and then we go for routing, or we do both. But or just talking only about the routing protocols and forgetting the internetworking, that's not the right path, I think. Thank you very much.
Ronald in't Velt: Okay. Two comments: internetworking is routing as well. And it's not only the chairs that should read drafts and comment on them, it's the whole working group. So what you were saying is just as valid for every working group participant as it is for the chairs. Thanks.
Don Fedyk: Okay. Thank you for the presentation and the drafts. All right. Get the next presentation up. Ronald, you're driving.
Ronald in't Velt: Yeah, but I get some strange error message. It says all slots for the media are already taken. Let me see. No, it doesn't. Here, I'll share it. Can you see it?
Ronald in't Velt: Yes.
Don Fedyk: All right. And just have to remember how to give Christopher-- go ahead, Christopher.
Christopher Dearlove: I wouldn't bother giving me control. All I would say on this slide is this is draft-dearlove-manet-olsrv2-responsive, but the only difference between draft-01 and draft-03 is I changed my email address. Draft-00 to draft-01, there was a change in presentation but not in technical content.
So this is the one slide. I gave a presentation of this draft, I can't remember if it was the 00 or 01 stage, back I can't remember which IETF it was, 120-something. So this is just meant to be a reminder summary of what's there, and it's a fairly simple draft anyway, so one slide will cover it. And as was said in the chairs' slide at the beginning, it's time to consider whether or not this should be adopted as a working group draft or "thanks but no thanks."
So OLSRv2 is a proactive protocol and the easiest mode of use of it is with regular heartbeat messages for Hellos and TCs, possibly jittered but that's... I'm back now. How far back do I have to rewind?
Ronald in't Velt: You were on the extra TC message.
Christopher Dearlove: Right. Okay, so OLSRv2 designed to be responsive in terms of sending messages not just on the regular schedule but in response to circumstances, so that's what we mean by responsive. You can consider a purely responsive use of OLSR. In practice, nobody's ever going to do that, it relies on reliable messages and things like that. Nevertheless, it's a useful case to consider because it shows you where there are issues that you then might want to address anyway. And in a purely responsive network, there's a problem that when a new router pops up, it will never find out about distant old routers because they've got no reason to send their messages, nothing in their neighborhood changed for them. But you can get round that by sending an extra TC message when that remote router, it will discover the new router's popped up because a new entry will appear in its topology information base. Therefore, it could send a responsive TC message and that would make the protocol work in the limiting case, whereas otherwise it doesn't work. In the less-than-limiting case where you're wanting to do things responsively and maybe things are changing slowly so you can send your heartbeat messages less often, that message is still useful. It accelerates convergence and therefore it's worth considering adding to the protocol. And it's safe to add to the protocol because it would be purely optional because, of course, people might not have implemented this hypothetical RFC, but it still works without it. It's purely optional, it's fully backward compatible, routers using it and not using it will interwork, and therefore it's a potentially useful in certain circumstances, small, very focused addition to the protocol. And that's my summary of what this thing is about, therefore saying this could be a useful addition offered as a working group item.
How do I give you back control of the slides? Do I just-- I presume I just click that.
Ronald in't Velt: Hello? Yeah. I put myself in the queue and I was the first one to do so, but actually, I would like to let other people speak first. So.
Don Fedyk: Yeah. I mean, I think it's a good piece of work. We do have to check with our AD if we could accept this. This is definitely within the charter and it's-- it looks like a fairly-- to me, it looks like a fairly simple small draft, so we'll see what we can do. But if there's any comments on the list, I'd solicit anybody else to make comments. Did you have, Christopher, have you had comments on the list before from people?
Christopher Dearlove: There was a couple of comments from... I apologize for forgetting the name. That was part of the motivation for changing from 00 to 01 in terms of focusing the presentation because they picked up too much on the idea of actually using it purely responsively, which wasn't really... I mean, there's an appendix saying, look, if this is how you would do it if you could but it has all these issues like needing reliable messages and so on. So that is there but stuck in an appendix if I remember correctly. Um, but other than that, which was useful, other than that, I don't think there's been any comments.
Don Fedyk: Okay. Thank you. Any other comments?
Fred Templin: Hi, this is Fred I'm on now. Christopher, is there a plan in place to implement this in some OLSRv2 implementation?
Christopher Dearlove: I wish I could. Back when I was working for BAE Systems, we had an implementation of OLSRv2 of absolutely every detail. It was developed in parallel with actually developing the protocol. I no longer work for BAE Systems, I'm retired, so I don't have access to that. Um, I have made tentative sort of moves towards them but without much to offer saying, look, could I have a license to use the software and I would put this into it and then they'd have a copy of that? Um, but so far that hasn't met anything. If this gets adopted as a working group item, I will push that again because that'll give me an extra little fillip to-- extra little tidbit. But even if that happened, that would not be a public implementation. The best it would be would be somebody, me, saying, "Yeah, it can be implemented." But I don't hold out a great deal of probability of success at that approach, you know, give it 10% say. Um, but that's-- that's, I'm afraid, the best I can do.
Fred Templin: Okay. Just as a matter of awareness, we've got a very strong interest in experimenting with MANET protocols right now, but we cannot find a public domain version of OLSRv2. Uh, I know I can get Babel from a public domain. So uh, I don't know whether you know of any public domain OLSRv2 implementations that can be used for experimentation purposes.
Christopher Dearlove: I thought the people you need to ask are... you could check with Justin Dean and his people, I don't know whether they had one. And I thought that the Freifunk network people were using one, um, which I've never myself played with. And um, I'm afraid my former employers failed to see any advantage in making the implementation they had publicly available. I don't think they've gained a great deal of advantage from not doing so either, but that's their-- that's their up to them, I have no influence there. So yes, I mean, across the... I suspect the biggest problem with me wanting to get a copy of it is the amount of commercial work in writing a draft terms and conditions for me would be something they'd say, "Well, yes, that's actually costing us effort." Um, but I will try. I will try if this gets adopted again. That's all I can say.
Fred Templin: Okay. Thank you.
Ronald in't Velt: So I can first address that question. Henning Rogge has implemented OLSRv2 twice now. His old implementation is still on GitHub, and I can publish a link to the mailing list. I'm using that and have been using that quite a bit, also because it has a router-side implementation of DLEP as well that you can add as an option. And then he did another closed source implementation in GoLang, which I think can be-- well, you can obtain a license for that if you get into contact with his employer, Fraunhofer FKIE, sorry. So there is-- there is at least one no longer well-maintained implementation out there as open source.
Fred Templin: Ronald, I was aware of that implementation and I've actually pulled it down from GitHub, but it does not build. It's not maintained anymore and I tried talking to Henning Rogge about it and did not get support from him on that.
Ronald in't Velt: Oh. Funny. Yeah, I confess to not having checked the very latest situation but about a year ago I was still able to build it with some tweaking.
Don Fedyk: The latest, three months ago, there are some updates that say "make it build." I don't know if you've looked at it recently, but perhaps it's fixed or perhaps it still hasn't broken.
Fred Templin: I'll take another look. Thank you, Don.
Ronald in't Velt: Then about Christopher's draft. I read it, I like it. It is a bit of a niche application, I think. You wouldn't want to use it in a very highly dynamic MANET environment, I would not think. As a non-native speaker, I'm a bit confused on responsive versus reactive, but that's my personal problem, I guess, and nothing to do with the draft. And yeah, if you go for the fully responsive thing, then indeed the presence of packet loss would make that difficult to use it.
Abdussalam: Yes. Regarding this draft, it's okay, but I'm not interested in adopting until we update or-- or I hope the authors bring up all the updates for 7181. Actually, it's more than 10 years now it was issued this RFC or the OLSR version 2. So more than 10 years and we have many updates. You know, if we go through the updates, it's difficult to bring up all and it's important that these updates, they become in one document, you know. If you go for-- it's a important routing protocol for our working group, and more than 10 years and now we are getting one draft which is an update which is a small issue, you know, it's a case study. So it can be-- it's better that we get a draft which brings up all the updates and includes this. Then it will be for me, I would like to adopt a full updates, all the updates and we include this update.
Christopher Dearlove: Well, I first joined the queue just to mention that, of course, there were implementations at the Ecole Polytechnique, Thomas Clausen and colleagues, since there was a PhD thesis on the basis of one of them, there was certainly more than one implementation, but I don't know whether anything was ever made public there and I don't think Thomas is retaining much interest in this group anymore. But there's someone to approach there. With regard to the last comment: protocols in multiple documents across it is the IETF way. I mean, you know, I don't want to compare OLSRv2 too much with OSPF, but you look how many documents you have to implement to implement OSPF, which I have done, um, and partially done. Yes, it could all be put together in one document if somebody was prepared to do that, and that somebody isn't me unless somebody's paying me, I'm afraid, which is not going to happen. So I'm afraid that's the state of the world. Yes, one document would be nice, but I don't see it happening.
Don Fedyk: Okay. So I think that brings us to the end of our agenda. Is there any other business that anybody'd like to bring up?
Abdussalam: Uh, regarding-- I'm sorry that at the beginning of the meeting I haven't listened to it. I had another thing. Is the charter of our working group going to be renewed, or have you discussed this in the beginning of this meeting?
Don Fedyk: We did mention that there was-- we previously had talked about it, but the AD, Jim Guichard, had said that we wanted to get the items that were on our charter through first before we discussed, and the number of people and the amount of interest in the group hasn't been very high. So in past discussions with him, it's been that we don't really have enough people to do that. So the current charter is all we have right now.
Abdussalam: Yeah, you know, Don, I'm interested that we continue in this working group with discussions. So what's your suggestion for us, how can we make it work? I you know, I have about maybe 100 students. Is it good that I bring up two, five students and I think all of us we can bring some people to discuss together and we have a discussion. It's not difficult. Or do you think it's difficult? Because I want to discuss this. If we don't have, once the AD said, I think you know that, he we need discussions. Okay, discussions need people. People, we can do it, I think, or we cannot. Let's discuss this also. Is it a problem to have people discussing in this working group? Could I ask this question, please?
Don Fedyk: Well, I mean, certainly, on-topic and, you know, discussions on the mailing list are certainly welcome. We just have not had that amount of traffic or that amount of things. And we've had the comment that because we don't have a number of people, there are other people that have had contributions that they have not considered putting forward because they don't think it's going to get through. So it's a chicken and egg problem, really. But, you know, we do have a couple of good drafts in the queue here that are on charter and we'll endeavor to get those through, but we really don't have a big push right now. So any-- anything you can contribute, I mean, a draft is-- is the most useful way to get things started.
Abdussalam: Yeah, but I think the thing is that if I'm going to write a draft, or say let's say any author wants to write a draft, he will not bring it to this working group because there is no discussion. So why he will bring it here? So our problem is not a draft, it's the discussion issue, or reading the documents and replying on each draft. Let's say now we have who we have four presenting, or two presenting persons today, and we didn't get much comments on this working group on the mailing list. And we have already let's say I'm included, a member or participant, so we could have discussed this. I hope that this comment that I'm giving now will encourage us also that we all have to give some time and please that we hopefully at least give comments on each draft even once a month at least. Once a month is okay, I think. So and sorry for my maybe it's a little disappointing, but what so I am encouraged I would like us to continue. That's my purpose. Thanks.
Don Fedyk: Thank you.
Fred Templin: Um, I just want to second that. I agree with what Abdussalam just said and I think that somehow the working group has got a pall cast over it that people are afraid to post to the working group. That's what the-- that's what the mailing list discussion is there for, is to discuss on the mailing list. So I don't know how the social norm got to be in place that people don't say anything on the list, but that should change. I think there's enough materials out there in MANET that are are are available for comment that people shouldn't feel like there's some gag order on being able to post to the list.
Don Fedyk: Yeah, well, I-- we've always asked for comments on the list as-- as far as we've been doing. I think, you know, the request has been there. It's been the-- the community that hasn't hasn't either had the time or the interest to to respond. But please, if you know somebody, or if you're listening now and you want to comment, please feel free to comment.
Ronald in't Velt: Yes, I guess you're right, Don. It's not so much that there is some gag order in place, I don't think that is true in any sense. It's just people not having the time or not willing to disclose what they're working on on an IETF mailing list. And in particular in the case of DLEP, I know that there is activity out there and I've trying been trying to persuade people to bring that to the IETF but so far without much success.
Don Fedyk: Okay. If there's-- I don't see anything else in the queue, anything else. I'd like to thank everybody for attending and we'll close on that and please take your comments to the list. I know I have a action item to get a few messages and I will comment on the drafts as a participant as well. So please, don't be shy on the list if you're listening and you've got interest in this. And for me, thank you.
Ronald in't Velt: Thanks for driving the meeting, Don.
Don Fedyk: Thanks, everybody. See people in NV.
Ronald in't Velt: For sure. In person.
Don Fedyk: All right.