**Session Date/Time:** 22 Jul 2026 09:30

[00:00:10] **Chairperson**: Good morning. Welcome to the MANET session. We have a full agenda today, so we get started right away. This is the note well. You have to familiarize yourself with this if you haven't already. It's on how to behave professionally and respectfully, in ITF meetings and, also the rules for, ITF contributions and what constitutes, what holds for IPR is also on there. If you haven't seen this for a while, maybe you should have a look at it again. Meeting tips, I think you noticed by Wednesday, but yeah. My cultures have been a bit creative and wanted to have something like this in the chair slides. This is a there this is AI's depiction of chairs. You wanna say something to this?

[00:01:40] **Co-chair**: Well, yeah, we we look happy in the picture anyway.

[00:01:48] **Chairperson**: Okay. Resources for this IETF meeting and more resources for this working group session in particular. There's the meet echo, full client, and on-site. There's a note that materials, chat, and audio. Sometimes my touchpad doesn't work. This is our agenda. We will go quickly through the document status. Back to the first bullets, we do we we we will have the recording. This meeting is being recorded. I should have mentioned it before. We also have the captioning and AI pro post processing of that. However, we would still be grateful for anybody taking notes. I will give you quickly go through the document status, and then we have three presentations. We've added Henning Rogge's presentation bit at the as a last minute thing. This means that we now have to do some strict timekeeping since we have only one hour. Document status. Yes. This is the first time where in the in this session where I have to make an apology. I dropped the ball on this. These things are have been through working group last call. Last year already, there's still some things that we want to resolve. So I I apologize to Henning, and I will try to get to this this week before I get home and get involved to into too many other things again. We have two newly adopted working group documents since the last I. T. F. The first one is by Fred Templin and his co author and will be presented as the first presentation in this session. The next one by Christopher Dearlove has been presented before. It's now officially a working group document. It's short and sweet, I would say. And therefore, we won't have this dwell in the working group for too long. We will subject it to a routing director at early review. And if that goes well, I think we can go fairly soon to a working group last call. However, in the meantime, we would ask participants to have a look and post any comments to the mailing list. Then we have individual drafts, personal drafts, two new ones and one that's been with us for quite some time and has a long history behind it. Both new personal drafts will be presented by Donald Eastlake and by Henning Rogge respectively. The other one, Charlie Perkins, AODVv2 draft, was presented a year ago with focus on the implementation status. Yeah. I haven't heard much about it since then. It's a pretty big document. We need to decide what to do with this. I haven't gotten around to doing a proper review myself. But we will we don't have time for a long discussion on this now, so we'll take this to the mailing list. Other business, there has been a rather posted against DELIP, RC8175. It was found by Henning and then reported officially as an errata by Donald Eastlake. And since we have Rick Taylor in the audience, I would like to ask you as one of the remaining authors and as far as I know, the only one still active in the ITF to have a look and let us know what you think on the mailing list. Thank you. Two ITFs ago in Montreal, we had a presentation on other deficiencies as perceived in 8175 and what to do. There was a sort of general consensus that we wanted to Do something about it in the form of an update or a base document. Nothing has really happened since then because nobody seems to have the cycles to work on this. Another thing to take to the mailing list. And that's the end of the chair slides. And that means Fred is up. I'll try to load the slides.

[00:08:21] **Fred Templin**: Are you hearing and seeing me?

[00:08:24] **Chairperson**: Yes. Both.

[00:08:39] **Fred Templin**: Okay.

[00:08:42] **Chairperson**: You should have slide control.

[00:08:47] **Fred Templin**: Now. Okay.

[00:08:48] **Fred Templin**: We got slide control now. Yes. Thank you. Okay. So this is about MANET Internetworking problem statement and gap analysis. So the MANET Internetworking background, the first concepts were presented at IETFs one twenty through 01/23. You see the links to the meeting materials here that you can go back to later and look at if you're interested. The MANET, you never can problem statement and gap analysis concepts were formalized in a dash zero zero personal draft in August 2025. The draft was updated based on list discussions and presented at IETF one twenty four and one twenty five. And then there was a MANET working group adoption call back in April and June 2026. And as a result, the MANET in a working Internet working problem statement gap analysis is adopted as a MANET working group by an impending issue resolutions in June 2026. And then I uploaded the formal working group draft with issue resolutions on 06/11/2026. The document has now been broken off into separate sections with one section being problem statement, the other one being gap analysis. And the problem statement is stable with few changes necessary. The chairs have recommended an emphasis on gap analysis in the continuation of the work. Now the draft is also up on GitHub now. You can go to GitHub and find the latest version of the draft. And if you wanna do an issue tracking, you can do that on the GitHub as well. So what are the gaps that we want to address for solutions that were are necessary for MANET Internet networking? Gap number one, multiple heterogeneous MANET interfaces. Modern cell phones like this one right here have both Wi Fi and five g interfaces. And the three GPP is in the process of standardizing five g sidelink, a MANET capability for five g. So when the cell phone operates outside the context of infrastructure, it should be able to do MANET over both its Wi Fi and five g interfaces without while redistributing and discover routes between the interfaces. When the routing is based on MAC addresses, the MAC address uniqueness within each interface type as well as between interfaces is critical. Heterogeneous media may use different MAC address types, preventing redistribution of MAC address based routes. Instead, we might just have to redistribute I p v six addresses carried by the routing protocol as as a router ID. Now cell phones are expected to become a dominant use case. There are lots of cell phones. It is said that there are more cell phones than there are people on the planet. That represents a an enormous use case for MANET. And so the the the goal of having having mobile heterogeneous MANET interfaces is something we're gonna have to we're have to address in solution proposals. Gap number two, maximum packet size diversity. Especially in the presence of heterogeneous media, MANET hops may support diverse maximum transmission units. So if a path includes an initial portion with large MTUs, say 1,500 or larger, and intermediate or final portions have smaller MTUs such as twelve eighty, large packets can disappear into a black hole. So we need to have some combination of fragmentation and path m t discovery, but both have known issues. So the solution probable proposals need to address this gap and tell how they they address the maximum packet size diversity gap. Gap number three, header compression. MANET data plane packets often include sizable upper layer headers, including any encapsulations, the IP header, and upper layer protocol headers. So especially for smaller packet sizes, the overhead for carrying significant header payloads can waste precious wire wireless transition bandwidth. Solution proposals must therefore address the need for header compression for multiple multi hop packet flows. Gap number four, MANET border router discovery and engagement. So ordinary MANET routers must be able to discover and effectively engage the best MANET border routers, especially when there are multiple alternatives present. So if if we had our MANET with, say, 100 ordinary nodes, it might include four MANET border routers that also have a longer range in networking links such as the lower lower third satellites. MANET nodes must be able to discover the border routers that may may be multiple MANET local hops away and somehow cause their packets to flow through the border routers that invoke MANET Internet networking. So any solution proposal must therefore address these needs. Gap number five, MANET Internetworking security. So the fact that a note is admitted into a MANET local routing region does not ensure that the note is authorized to establish flow state in the MANET and/or invoke MANET Internetworking services. So for that reason, the gap exists that requires a solution for securely admitting MANET clients into the MANET Internetworking service. So any any solution proposal must therefore address the security gap. So the plan now for the document, in addition to finalizing the gaps that we see, there may be others. The these are the five that are in the draft currently. If anyone has all the gaps we should be looking at in the gap analysis, please take that to the mailing list. So in terms of solution proposal analysis, the draft enumerate solution for alternatives requiring gap analysis. Solution, Nemo, LISP-based mobility and overlays, hip mobility, DLEP-based MANET developments with the gateway, and conventional tunneling and prefix delegation approaches. So the plan is to solicit contributions from solution owners for future draft versions. In terms of the schedule, the draft authors are gonna resolve any further problem statement issues, by the end of August, reach out to the solution owners at the beginning of September. Each solution owner is to provide up to one page of gap analysis text by mid October. A first approximation of the gap analysis text will be in place ahead of IETf-one twenty seven, then engage in list discussions and gap analysis after 01/27 up to January 2027. Final draft will be ready for working last group last call in February 2027, and working group last call concluded by IETf-one twenty eight. This is an aggressive schedule. So some questions for the working group. Draft currently speaks generically about MANET local routing protocols, but should it also enumerate the routing protocol alternatives? The ones that I'm aware of include OSPF MDR, OLSRv2, Babbel, AODV, Batman, and also proprietary systems such as Syllabus and Persistent Systems Systems. Are there others? So the question to the working group is, should the draft enumerate these routing protocols or just be silent and called the MANET local routing protocols? The plan is that the draft's authorship would remain unchanged with solution owners named as contributors. Will that be acceptable to the working group? And, again, the schedule is aggressive, but it's necessary to avoid an open ended effort that never reaches conclusions. Any thoughts on the schedule? I think this brings me to my last chart.

[00:16:40] **Chairperson**: Do you want to take questions now?

[00:16:45] **Fred Templin**: Sure.

[00:16:47] **Chairperson**: Because we have three people in the queue. Christopher, you're first.

[00:16:52] **Christopher Dearlove**: I was just gonna say with regard to routine protocols, I would split between those that the IETF has standardized or experimentalized, if that's the word. We're hardly audible. Sorry. I would say with regards to the routing protocols, I would I think you can mention the ones the IATF has standardized or experimentalized, if that's a word, the OSPF, the OLSRV2, the Babel. But the ones that it hasn't, the AODV and the Batman, there are so many of the latter that I wouldn't go I wouldn't go into those.

[00:17:34] **Chairperson**: Thank you.

[00:17:40] **Lou Berger**: Do you mind going back one slide? Given that you haven't presented the problem statement issue sorry, the problem statement, How do you plan to resolve any issues in the problem statement?

[00:18:00] **Fred Templin**: I as list discussion, I I assume. I'm hoping people are reading the draft and bringing the issues forward on on the mailing list.

[00:18:08] **Lou Berger**: I don't see that you've addressed the issues, at least the ones that I've raised on, in adoption, nor have I seen discussion on it.

[00:18:22] **Fred Templin**: I apologize, Lou. I'll go back and look at your email again and make sure that I've addressed it, but I thought I had addressed you what you were asking.

[00:18:30] **Lou Berger**: Yeah. I fundamentally don't understand the presumption of a MANET overlay, a global MANET overlay. And I don't understand why interworking is not simply talking to the rest of the Internet. And I would like to see that addressed before even going into gaps because as soon as you do gaps, you're assuming a particular architecture. I don't think we have agreement on your problem statement.

[00:19:00] **Fred Templin**: Okay. Lou, I I I did take your your your your comments, and I tried to put text into the draft that addressed the comments. But, apparently, you you you you wanna see more discussion about that.

[00:19:20] **Lou Berger**: The document still has a presumption of a MANET overlay. Is that correct? Am I misreading it?

[00:19:26] **Fred Templin**: Yes. But it it justifies why that that assumption is there.

[00:19:33] **Lou Berger**: It it doesn't make any sense to me. Maybe I'm alone.

[00:19:43] **Chairperson**: Steve?

[00:19:45] **Steve**: Yeah. Advance again the slide if you would. Yeah. So to the first point there about do we talk generically or do we talk specifically? I like talking generically to have general solutions, not point solutions. However, I think we need to talk specifically because otherwise, we're never gonna get to where the real problems are. When we talk about, you know, inter operation between MANETs with different local routing protocols, that's where the rubber is gonna meet the road, I think we have to go there.

[00:20:20] **Chairperson**: Okay. Thank you. Henning?

[00:20:24] **Henning Rogge**: I also have a problem with a few of the problems provided here. Feel that this is something we talked about most likely ten, fifteen years ago because this smartphone as the new MANET platform that was the new big thing when Android and iPhone hit the road, and we quickly discovered none of them has the capability to even use something like a MANET over Wi-Fi without some jaded breaking, and it didn't got better. I'm not sure that the five g editions will help either. We don't even know if they will be available if the five g cell is not available. If the five g cell is there, there's no point in doing a MANET because you have a high speed backbone connection to the Internet. And the document also talks about this scalability issue of billions of nodes. I don't think it makes sense to talk about this peer-to-peer MANET aspect with billions of nodes. We all know if you're talking about small host routes, it doesn't scale that well. That's why the Internet works in large prefixes that can be aggregated. But this means, of course, a node switching from one MANET to another one will just get a new source address from a local MANET pool, and nobody in the Internet will know that it's a MANET node anyways. So I'm skeptical about a few of the problem statements.

[00:21:55] **Chairperson**: Okay. Roland?

[00:21:58] **Roland Bless**: Yeah. I think I I second what what also Lou said. So so I I'm not sure. I have to reread actually the the latest version. So, I mean, I designed OLSRv2-responsive, which may be a solution for everything that is stated as problem in the draft, scalable, and and what have you. So I just have started to work on getting fallback connectivity where you can have routers in the MANET advertising that they have. For example, five g connectivity to to the Internet, and then you can simply couple different OLSRv2-responsive domains, let's say, via the Internet if you want to. But yeah. So in that respect, I cannot say at this point that that OLSRv2-responsive is is a good money routing protocol because I have not so much experience with, let's say, real world deployment of of that. So it mainly just simulated, but so I'm I'm not sure about the problem statement. And, I mean, as I said, it's OLSRv2-responsive is not not as yeah. Not so much experience with that compared to OSPF version two, what have you, other MANET protocols that are out there. So, yeah, I'm I'm not sure also about the the gap analysis then. So we we have, let's say, standardized ITF protocols, other protocols from other domains like Batman, what have you, and even, let's say, new things coming up that might be a potential solution. I don't know how to actually evaluate these or compare these, so that's maybe a difficult task as well.

[00:23:44] **Chairperson**: Thank you. Don?

[00:23:48] **Co-chair**: Thanks, Fred. I I like your your scheduling and the fact that you've got GitHub. I would suggest for these items, the questions that you, you know, have a separate subject on the mailing list, and you try to close off so that, like, we don't have issues where somebody says, well, I raised this issue and it wasn't wasn't covered. So, you know, utilize the the mailing list, and we'll try and help you make sure that things get closed off. You know, you you you don't have to put all the text in the thing. If you've got the GitHub, you could have I think you could point to the document there where it's addressed and just have the person get back to you if they're happy with the resolution or not.

[00:24:35] **Chairperson**: Okay. Just before I let Lou comment further, how many more slides do you have?

[00:24:47] **Fred Templin**: I'm I'm done with my slides.

[00:24:48] **Chairperson**: He's done. Okay. Okay. And, Lou Yeah.

[00:24:54] **Lou Berger**: I'd like to request that we get some meeting time to discuss the problems and have a discussion about these. I I actually completely agree about the cell phone model. It doesn't make sense to me. The interworking model, I think, is a bigger issue. But, yeah, I I I think we need working group discussion time like what we come together in here and have some higher bandwidth, higher throughput exchanges than just the mailing list. And, you know, the the answer of, well, I wrote it. I mean, I'd love to see you present it because I've I don't I don't understand how what you wrote addresses at least my point and certainly the the point about the the all the the cell phones in the world inner interworking over an overlay, that that that's even a bigger stretch. And, you know, I think I think we have to have some real discussion time on this rather than just doing it on the list. Because asking a question and saying I answered it, and what's there should be good enough, it at least isn't working for me. And me saying, I think you're wrong, and that's about the exchange or the level of exchange we're having in email, we're not getting there. We're not closing the issues.

[00:26:12] **Co-chair**: So you'd like to see, like, an interim?

[00:26:14] **Lou Berger**: You could do it on an interim or could have done it in this in this you know, typically, after a working group document is adopted, you review the open issues that were raised during the adoption and then go through how each of those issues was addressed and make sure that the working group buys into that.

[00:26:31] **Chairperson**: Right.

[00:26:32] **Lou Berger**: We didn't have that here. We had, oh, it's all done. We've addressed it, and then no discussion. Now we're just looking at gaps. So, you know, I I I think we we we skipped a step, and it would be good to have that discussion.

[00:26:44] **Co-chair**: Okay. Well well, we're fairly full today. But if we have extra time at the end, we'll try to

[00:26:50] **Lou Berger**: I don't I don't think it's fair for to ask Brad who

[00:26:54] **Co-chair**: who did

[00:26:54] **Lou Berger**: come prepared. I'm not asking to do it right now on the fly. I don't think that's fair. I I think he

[00:27:01] **Steve**: he should But I didn't I don't

[00:27:02] **Henning Rogge**: time to prepare.

[00:27:03] **Chairperson**: Yeah. I don't think

[00:27:03] **Co-chair**: we wanna wait another meeting too, like, another cycle if we can

[00:27:08] **Lou Berger**: Sure. I you know, things take a while and but, you know, it's not like this conversation isn't one that's been going on for years.

[00:27:15] **Co-chair**: Alright. Okay.

[00:27:23] **Chairperson**: Okay. Thank you, Fred. Yes. They will think about an interim and not postponing this until San Francisco. But in the meantime, I still would like to see more discussion on the mailing list on this even though, yeah, I understand the the bandwidth problem that Lou just mentioned. I'm going to bring up Donald's slides. And, Donald, you should have control.

[00:28:28] **Fred Templin**: Go ahead.

[00:28:28] **Donald Eastlake**: Okay. Yep. I will go ahead. So I'm Donald Eastlake, and I'm gonna talk about adapting the Babel routing protocol for IEEE 802.11, which is the Wi Fi standard mesh. So these are the topics I'm gonna cover. I'm gonna go through the earlier slides fairly quickly here, in the interest of time, and you can all study them at your leisure if you wish. So Babel is intended to sort of come under the MANET umbrella at some point, although that will require a charter update. So distance vector algorithm with nifty improvements to avoid loops and starvation. It has been proven effective in networks consisting of varying quality links and those with time varying characteristics such as wireless or hybrid wired wireless networks. And it's been standardized by the IETf. These pointers will give you lots more information. There are multiple open source implementations. So this is, so this is about eight zero two eleven mesh, which people may be somewhat less familiar with. Originally, it was intended, just as a wave whereby access points could use, multi hop through other access points back to the wire distribution. So it'll be an additional feature in an access point. So you could do that, but it was sort of generalized and really now eight zero two eleven mesh. This looks like a link, a multi access link. The mesh points can also be access points and provide service and so forth. So the various stations send mesh beacons normally, and that includes various characteristics that have to match up for the mesh stations to pair and become part of the mesh. In general, in the middle of the mesh, if you have a frame coming from outside going through the mesh and then back out the other side, you have six addresses in the eight zero two eleven header. The ultimate source and destination, the points where it enters the mesh and leaves the mesh, and then for each particular hop, the radio transmitter and receiver. So this is all, of course, the eight zero two world. So the assumption is everything has to work if everything is layer two. So you have a multiple access to this mesh link, so to speak, we'll call it. And it how do you avoid loops? You just use spanning tree in there. Of course, if the mesh connections to the outside world actually go to IP routers, then there's no problem since the IP routers bound the bridge to layer two area. So the mesh uses a pass selection protocol and a link metric to determine how to forward frames. But when eight zero two eleven s was developed, it was realized that there'd be lots of different mesh conditions in terms of density and whether the stations are battery or are on fixed power, so on and so forth. So it was always designed so that you could specify for a particular mesh different path selection protocol or or link metric or whatever. Currently, the standard has only one path selection protocol, which is called hybrid wireless mesh protocol based on AODV with some tree based additions. There was earlier a radio aware OLSR option in there, but that was taken out before the standard for eight zero two eleven mesh was finally approved. So this eight zero two eleven s has long since been rolled into the main eight zero two eleven standard in the eight zero two way. So the the only case you're interested, the eight zero two eleven standard twenty twenty four edition is almost 6,000 pages. This for that's, I guess, moderately long. But, like, eight zero two dot three, which is Ethernet, The standards document covers exactly how to do all flavors of copper and fibers over the eight zero two dot three standard for Ethernet is currently, I believe, over 22,000 pages long. So, anyway, there are implementations that I said. There are products available that advertise Wi Fi mesh, but they do not normally conform direct exactly to the standard. So what exactly would be available for a two two eleven mesh? Primarily, a way to specifying how to use the available routing protocol as a mesh path selection protocol inside an eight zero two eleven mesh. There's also the delay based metric, which has, been specified for Babel, which might be useful in, eight zero two eleven. And you might also wanna use the 802.11 airtime link metric in in Babel. So that's less least important, I think. We have explicit we not only is eight zero two eleven mesh design, so you can do this very easily, obviously, but we have a explicit permission and an explicit liaison. Of course, eight zero two eleven doesn't specify whether they think it's good or bad exactly for the idea of doing this. They specifically say, however, they have no objection, and they even volunteered to be helpful in obtaining code points if that should be necessary. Although the design for eight or 12 mesh should not is such that you should not need to get any additional code points other than those already provided in the flexible format. So what do we have to sort of do in some sense for eight two eleven? Actually, you have to when I divided it into three questions. One is forming an eight zero two eleven mesh that uses Babel protocols, how to exchange the Babel routing messages between the mesh stations inside that mesh, and what would you need to change things about the Babel routing protocol? And, yes, clearly, some changes are necessary. So the as I mentioned before, I think the mesh stations peer with each other and form a mesh if they have the same mesh profile, which is something explicitly defined in the standard. And it consists of a lot of things, the mesh ID, which is just like an SSID, but it's identifies the mesh. A bunch of fields in the mesh configuration element. It's an element that appears in these beacons. Also, if you if they are not beaconing, you can do a probe and get a probe response that has it. Also, when you actually peer, do the mesh peering open and mesh peering confirm message between eight zero two eleven mesh stations, it contains this mesh configuration element. That element include includes a path selection protocol identifier and a path selection metric identifier and a whole bunch of other stuff. There's a collision avoidance protocol identifier, the security protocol identifier, etcetera. But the ones we're interested in are the past selection and metric. So the way you can do use whatever you want for those things, so to speak, is in the mesh configuration element, you specify the identifier as all ones, x f f. And if you do that, it basically means that the actual path selection protocol and or path selection metric are defined by a vendor specific element is what they call it, typical eight zero two protocols. So that's here's what what a vendor specific element for the IETF would be or actually one allocated through ENA. We use the ENA OUI to identify the the organizational unique ID to identify the the IETF. And then the the ways are all structured with a subtype and a content where the link field there gives the length of the of the content. So you really don't wanna include lots of different vendor specific elements unless you have to. Beacons are, say, transmitted periodically, and if they get too big, it tends to use up a bunch of bandwidth. So one thing you could do is use the subtype field there to encode whether you're using the routing protocol, delay based link metric, or both of those. And you would do that in conjunction with setting the specific protocol selection identifier, for example, to f f, that will indicate what you're doing. And mesh stations will only appear if they're both advertising the the same protocol selection, path selection protocol rather, and path selection metric. So I think this is pretty much the right way to do this, and it's kind of answers the first of these three questions that I posited. Same question about how exchanging Babel routing messages. This needs further work. I I like to comment here at this point that in general, this this draft that's being referenced as a personal zero zero draft is incomplete. It doesn't cover all answer all these things, And it's got us some rough edges, so draft needs more work as well. So how you exchange these, they obviously need an appropriate encapsulation as eight zero two eleven control frames. So you could put them into the content portion of a vendor specific element if you happen to be sending one of those in some some control message. So, for example, in the these beacons, it would be a very logical place to stick a a hello. You probably have to send additional people hellos, but, that would be a good place to put them. And there's no other in the answer to question one, I didn't suggest any other use for the content portion, so that seemed like a reasonable thing to do. The other question is what changes do you need to make? This needs further work too. Clearly, you need to be able to specify MAC addresses because that's all in the eight zero two world and the eight zero two eleven mesh works in terms of MAC addresses. So you need an address encoding type. You don't need to carry prefixes. You can do it with MAC addresses. And Julius, who I noticed is not on the call, unfortunately, did send an email message to the list, which I have the URL for here, in which he listed what quite extensive changes. Changes sufficiently extensive that if those were made, I think perhaps it shouldn't just be called Babel anymore, but Babel l two or some other kind of name to clearly distinguish it. So two and three do need additional work. Just some some notes. Babel is very flexible on link metric. So you could if you wanna doing the l the regular Babel as currently standardized in l three using the delay based metric or sorry. Using the eight zero two eleven's airtime metric should be very easy to do. Another interesting point is that eight zero two eleven mesh and eight zero two eleven in general provides all its own security, you don't need to worry about the the specify the standardized Babel security. And it is the interesting side. Mesh handles multicast and broadcast by flooding and pruning duplicates. Basically, of the source of the where the pack frame enters the mesh, It when it forwards them, there's the that source address and there's a frame number. And when those are duplicated, you know you have gotten a duplicate. So it doesn't really need any routing in some sense to handle multicast and broadcast. So, there are these two open questions, particularly items two and three above. The draft needs more work, and, all these issues need some discussion, particularly whether Julie uses, mailing list messages corrected to the extensive changes that he seem sees as would being good changes to make to the Babel, protocol to make it applicable, inside, eight zero two eleven mesh. So I guess I open for questions or comments at this point.

[00:40:55] **Chairperson**: Okay. Thank you. Anyone want to comment? Fred?

[00:41:06] **Fred Templin**: Yeah. So with I I don't think I can call it the traditional main approach that was IP based routing. It's very critical that the there'd be no duplication in IP addresses, but not necessarily as critical that there'd be no duplication in MAC addresses. But when you move the routing protocol to the MAC layer, then it becomes critical that there's no duplication of MAC addresses. So how can we be sure that if you run Babel at layer two, there won't be duplication of MAC addresses?

[00:41:38] **Donald Eastlake**: I I I'm not sure you can ever guarantee absolutely that there is no duplication of either IP or MAC addresses for any routing protocol. So currently, these things are observed to to work regardless of this. I mean, if you have multiple stations with the same MAC address in an infrastructure, Wi Fi setup, then you have confusion where they're both getting, you know, copies of of frames and perhaps both sending frames to get merged or something in some stream, problems like that. You know, it it sort of depends on the particular aspect you're talking about. But when you can detect this, you can do things, and they can dynamically re renumber the MAC addresses and things like that. But I don't see that there's any way to guarantee that a routing protocol will operate perfectly.

[00:42:52] **Fred Templin**: Right. The the point being that the duplication of MAC addresses isn't isn't a critical problem if you're working at the IP layer, but it does become a critical problem if you're working at the MAC layer.

[00:43:04] **Donald Eastlake**: Right. So given that, what is your conclusion? That that nobody should ever use eight or two eleven mesh?

[00:43:15] **Fred Templin**: Oh, I'm not saying that at all. No.

[00:43:17] **Donald Eastlake**: Well, I mean, the current mesh, HWMP protocol uses MAC addresses. So if the if duplicate MAC addresses screw up routing, they screw up the currently existing eight zero two eleven mesh routing. This in a, you know, way somewhat similar to the way they might screw up Babel.

[00:43:35] **Fred Templin**: Right. But the the the scenario that I'm supposing though, and this goes back to the question that came up during my talk, is that the cell phone population in the world is on the order of billions of nodes. Any any two nodes that come together could have a pension pencil of having duplicated addresses. And I'm not talking about having all cell phones in the planet be in the same manner at all. I'm talking about maybe a few tens of nodes that come together in a common operating region, making sure that there's not any duplication among those that small group of 10 nodes that gets together and forms a little MENE.

[00:44:10] **Donald Eastlake**: Mhmm. Well

[00:44:13] **Chairperson**: We're actually out of time for Yeah. Yeah. This part. So so I can grab a

[00:44:21] **Henning Rogge**: slide. A comment from the practice. A practical layer two MANET is completely broken if you have MAC address collisions because your MAC layer doesn't work anymore. It doesn't matter if you have unique IPs. If you have MAC collisions, communication breaks down on layer two and layer three doesn't work well anymore.

[00:44:39] **Chairperson**: Okay.

[00:44:41] **Donald Eastlake**: Anyway, people welcome to comment on the list. They they say this the the draft is an early and incomplete draft, so it needs work.

[00:44:53] **Chairperson**: But thanks for taking the trouble to write this up anyway. Whether we can actually work on this is another matter, whether this is covered by our current charter. I forgot to mention that Jim Bishart couldn't make it to this meeting due to an agenda conflict, but we would have to talk to him, I think.

[00:45:30] **Henning Rogge**: So

[00:45:32] **Chairperson**: I think you're

[00:45:34] **Henning Rogge**: Okay. You should have covered just a very short talk about our work on a MANET Awareness Model. So just talk why another data model for MANET, what the model does provide, Where the data could come from? And what would be the next steps? Why another data model? We lack a data model that can represent the big picture view of the router's knowledge. We have protocol specific stuff. We have vendor specific stuff, but nothing that just gives you an overview what's what's in there. And we would like to do this with the tools we already have and not reinvent the wheel. So we went to direction HTTPS, REST or RESTconf JSON, something easy to use. What should the model provide? Primarily network topology. So what links does the current? What's the low does the local node know? They are interface specific. You have very detailed knowledge, but very local knowledge. What does the note now about the network graph? And how what routing what endpoints can we reach and what attributes are on these three categories? So what what do we know some link speeds or speeds for an end to point routing? We would like to put this in this model. Second thing, what we have discovered in last years, there's no good way for services to find each other in a minute. So we would like to have a generalized place where we can publish on which IP addresses and port numbers we have certain services. Some applications try to implement this themselves. Most Manet are not multicast capable, so this would be a good way, especially if we have a general protocol to distribute service IDs to publish them to services and applications. And the third part, which is especially interesting for moving nodes like drones, is geo position data. Most applications dealing with this, again, try to distribute it themselves. The applications that you do useful stuff with geolocation data get more. And if every every one of them does the distribution of the data themselves, we, get a very inefficient thing. So it would be nice to have a central place where services application can ask some local back end service, hey, what's the position of nodes in the network or what do you know about them? Where does this data come from? Typically, especially the link data comes from the radio attached radios, maybe over DLEP, maybe over SNMP. Some knowledge will come from the local routing protocol, some of them about links, some about about the network graph or about the routing tables. You might have some applicate local application on the router that monitors the traffics on the interfaces. You could add this to the model saying, hey. This is the traffic patterns I'm seeing currently. And some parts might be just configuration data, like, what if you do multi topology routing, what are these topologies and what features do they provide and what restrictions they demand from the applications? So what what comes next? We would like to discuss the structure of the model and what the model provides. There needs to be a discussion about push notifications, what kind of data is interesting for service and applications that needs to be updated very quickly. So we could have some event, like server sent events. And some parts might be interesting about write access to the model, especially for things like service registration that a local service can just say, hey, I'm here, and then the router does some or part black box thing to distribute this data to the other router instances. One important thing is this is just a data model. We don't propose any protocol doing the work in the background. This is just an access point from a router, not the routing protocol, the whole router to a service level or an application level. So the idea is that any kind of back end should be able to fill in this data. Questions? I think we have five minutes left.

[00:50:20] **Chairperson**: Yes. You found it, apparently.

[00:50:28] **Rick Taylor**: I finally found the button. Hey, Henning. Good to see you. Yes. So I totally approve of what you're trying to achieve here. I think it's perfectly valid and very sensible that there is actually a unified a way of getting this information out of out of MANET devices. I do question whether an entirely new approach, and I'm not sure whether you are suggesting that, so I suppose that's my question. Are you suggesting an entirely new approach to data modeling and providing this information out of these devices, and how much can just be done by a gap analysis of existing young models and working out what is missing in order to provide the many specific bits that don't I mean, the IATF has created a lot of young models and a lot of ways to, you know, rest conference you point there is a good example or netcom for or whatever's coming next with gRPC whose name escapes me. Yeah. Let's not reinvent would be my question. So are you proposing a reinvention or proposing of a

[00:51:36] **Chairperson**: Yenglish statement?

[00:51:36] **Henning Rogge**: I would say most IETF young models are very protocol specific and very detailed. There's no young model where you can provide some general data about the network structure that fits to a MANET with all its strange parameters. We have an OLSR model. But if you want to use the OLSR model, you need to be compatible with OLSR. I would like to have something a little bit more generic, and you don't care if it's bubble, OLSR, or whatever below there, where you can put in you have a DLEP endpoint, for example, on the router. I would like to export this stuff for services and for applications because DLEP is only point to point.

[00:52:21] **Chairperson**: So Mhmm.

[00:52:22] **Henning Rogge**: We have no way getting this information if we are not the DLEP endpoint on the router. So there's some overlap, but most likely, we will have a lot less details in this model than some of the specific models of the IETF when you go to so these are not meant to give all the fine details. This is just a big picture overview combined into one model that is especially protocol independent.

[00:52:52] **Rick Taylor**: Okay. Again, I I can see why you might want that. I think where you may come unstuck is one person's opinion of what a high level detail is and another person's opinion of high level might differ. And I wonder whether having the basic information in the very, very rich Yang models that the IETF produce allows some high level management function to distill out the sort of high level operational picture. Mike, I am just trying to reduce the amount of work you're You signing up to

[00:53:30] **Henning Rogge**: easily feed this model output by querying your known specific model output you already have. Yep. So there's no this is just a stand way when you say I want to have some summary what's going on, and I don't want to know what protocol you're using. So I cannot use the old version two protocol because I don't care which routing protocol you're using. I don't want to be routing protocol specific on the client. But if you are the vendor that produced the router, you can easily extract the data you already have in details, just dump it down so it fits into the big picture model and then publish this on a second pass on the same RESTCON server.

[00:54:15] **Rick Taylor**: Okay. I'm gonna yield to Lou who's behind me in the in the queue because he knows a great deal more about the extensibility of generic routing models and specifics for particular protocols because I don't think you're the first person to to have this problem.

[00:54:35] **Lou Berger**: Hi, Lou Berger. I'll answer your question, but first, I'm

[00:54:40] **Chairperson**: gonna go I think I'm gonna jump it up.

[00:54:42] **Lou Berger**: So when one of the questions I had was, is this just a DLEP model, or is it something broader? So I think you've answered that, but I do think you've identified a gap where we don't have and I was just looking for it. I don't see it. We don't have a yang module for DLEP. So if you're at you're suggesting that you would like to be able to expose that information, I think that is quite a legitimate observation and a good thing to do. I have no idea if that's your intent.

[00:55:16] **Henning Rogge**: I would say DLEP, the information has a place in this model as in the link section, as have, for example, the NHDP information from for which we wrote for Olasrv because both are link specific. But there's a lot more to know. Sure. And so I'm not sure if writing a DLEP YANG model would really help that much.

[00:55:42] **Lou Berger**: I suspect there is a gap in the existing link modules that exist that don't capture those two bits of information. So building one, probably a good thing. With respect to the routing information and the topology information, there are many existing models available from the IETF, and I would suggest you go look at them and identify whether or not there's a gap. And if there's a gap, then consider augmenting them rather than doing something fresh. That approach has been taken in multiple working groups, and there's no reason this working group can't follow the lead of what really has been typical practice in the IETF. Another practice is looking at a set of modules that are available and identifying which of those collectively give the information you want for a particular application. That's been done a lot in the TEAS working group, for example, or some of the service working groups. So I think I think not starting from scratch is probably the the right thing to do. Look for the gaps and fill them either by new or by augmentation.

[00:57:18] **Chairperson**: Okay. We have three minutes left. I don't I thanks for the good discussion, by the way. And let's continue on the mailing list.

[00:57:35] **Lou Berger**: One other minor thing for heading. Sure. Make use of trees in your document.

[00:57:40] **Chairperson**: Trees. Okay.

[00:57:41] **Lou Berger**: YANG trees are really helpful in in getting the gist of a a yang module.

[00:57:54] **Chairperson**: Yeah. I don't have that much to say anymore. Any words of wisdom for my co chairs, the one local and the one remote?

[00:58:05] **Co-chair**: Well, just just a point about I I did see that the Yang model does validate on Pyang, and I did generate a tree from it. But I had very little time to review it, so I'll take that to the list. Yeah. And and on the other points, we'll try to make sure that these outstanding issues get get cleared up and tracked so that we we we don't encounter the same thing the next

[00:58:39] **Christopher Dearlove**: meeting. Yes.

[00:58:43] **Chairperson**: Donald, anything from you?

[00:58:45] **Donald Eastlake**: Nothing special from me. No.

[00:58:46] **Chairperson**: Okay. Then thank you all for your attention, and we will just as you are sit here and wait for the the session to time out. Well.

[00:59:02] **Co-chair**: Yeah, we'll see you in San Francisco.

[00:59:06] **Chairperson**: Thanks again.