MANET IETF 121 Dublin Minutes Tuesday, 05 November 2024 , 18:00-19:00 (18:00-19:00 UTC) Room: Liffy Meeting Room 2 Chairs: Donald E. Eastlake 3rd (Indepednent) Don Fedyk (LabN Consulting) Ronald in't Velt (TNO) Area Director: Jim Guichard (Futurewei Technology) (Times are the amount of time originally scheduled for each item, not the amount of time actually taken.) Chairs, Administrivia (5 min) ----------------------------- https://datatracker.ietf.org/meeting/121/materials/slides-121-manet-chair-slides-01 Ronald in't Velt: Welcome to MANET this is the Note Well. You should take notice of this. Working Group chairs have been instructed not to try to read reinterpret what is written here in their own words. So just go read it. Which also holds for the Note Very Well which is about being nice to each other. It literally says, treat with dignity, decency, and respect on the second bullet. Don't harass people. If you feel that you are being arrested get in touch with the Ombudsteam. Meeting tips where you can find what to do. Resources for IETF 121 as a whole, some specific links for this session, and then our agenda for today. We have three presentations then we have some room for charter discussion. Ronald: Before all of that we will give an update where we are with the drafts that are out of the Working Group or still in the Work Group or might be accepted into the Working Group. Is there anyone who wants to bash the agenda and is there anyone who is willing to take some notes? Anyone in the queue? [no response] Ronald: Then we go to draft status: There are these four drafts on credit-based flow control that have been with us for a long time. We still have not managed to get them into the [RFC] Editor queue They're in the states that they have been. They are being reviewed by directorates of the various areas. We still need to respond to a number of those comments. We have lost and literally lost two authors of this whole set of drafts. The remaining authors are of the opinion that is taking far too long. It has taken far too long. They don't have the energy and the time anymore. We understand this. So the Chairs have decided to help out. We have to find it up to work among ourselves and we are going to successively address all these area directorate comments. Donald [Eastlake] has already made a start with it. Don [Fedyk] is probably going to be an editor of at least the classicification thing. You want to speak to that? Don Fedyk: Sure. I'll, I've gone through all the comments on the traffic classification draft, but we have to get the authors to sign off on them and we're in the process of doing that. It's all public, what we've got. We've got it on Lou Berger's GitHub page. So if you just Google louberger, you could look at the DLEP extensions. And so I'm doing that for the traffic class classification. Eric Kinsey has been doing that for the credit flow control. And Donald [Eastlake] is doing the IP and the Ethernet extension drafts. In short work, we should have new versions out and at least attempting to address all the outstanding comments from the people to get everything moving again. Ronald: Okay so moving on to active Working Group drafts. Just this morning these have been reactivated. They had expired. We really want to see some more review of these before we think we can move to workgroup Last Call. These have also been around for a long time as individual drafts. They got accepted into the Working Group late last year. I think they are very short drafts. Comment on these drafts if you haven't done it before and you can even say: "Yeah, they're fine." but don't stay silent. And we have two individual drafts that are related to MANET. Ronald: I ran into the the leading author of the first one, David Lou from Huawei, yesterday and he said that they are trying to keep this draft alive by producing a new revision before it's expired but they're rethinking the scope. This was presented in San francisco at IETF 117. There was a fair bit of comment on it and amongst themselves the authors are trying to make up the minds what to do with this at this stage. They did not see the need to present it again in the Working Group. Ron: Christopher Dearlove is going to update his draft or has already done work on this, but not send it yet, but will do so shortly, if I understood him correctly. I don't want to put you on the spot, christopher, but if you have something to add to that feel free. Jim Guichard [Area Director]: So I had a couple of comments that I just want to make. Just to make things clear. On that first slide, with those four documents, just to make it clear to the Work Group, I'm ready to go. So you know, the comments that are there, as far as I understand it, are based off of the IETF last call. I don't intend to review those documents again. As soon as you tell me they're ready I'll ship them. I don't want to be the bottleneck here. I don't think there's huge changes to those documents as far as I can see Also, I've been keeping to the the assumption that you want to me to put all four of the documents through all in one go. If you tell me, no, Jim, it's okay. You know, you can put this one through now separately or what I'm happy to do that. It's just that they sat there. There are comments that need to be, updated, and I can't do anything until and you do that because they've got to be gotten to after IESG evaluation or no.t So just so you know, I'm ready. So just give them to me. Jim: The other documents that you talked about, the other work in the next slide, you know, my comment here would be, are you utilizing the directorat? Because, if nobody in the working group has the the time to do those reviews that you're looking for, I don't want them just sat there in the Working Group. Let's get the directorate to, step up and actually review those documents. And if the comments coming back from that are okay let's get those moving. So I'm kind of keen to unblock this thing and let's get going. So we can then talk about the recharter and the new work that you guys want to do. I just wanted to make it clear. Ronald: Thank you. The ball is in our court. We have to address comments on these credit-based flow control drafts before. As far as these drafts by Henning Rogen are concerned Don has commented on one of them, I think between the previous meeting and this one And I because these were refreshed this morning I did not check yet whether those comments were addressed in the new version. Myself, I want to at least on short notice comment on the radio quality one. I think I have commented way back when on the channel utilization one. I will dig that up and repeat what I had to say about it. Christopher is in the queue Go ahead. Christopher Dearlove: You summarized my question entirely correctly. AERO/OMNI Autoconfiguration Services for MANET Internetworking (5 min) ---------------------------------------------------------------------- Ronald: We need to bring up the new slides. Fred are you ready to present your slides? https://datatracker.ietf.org/meeting/121/materials/slides-121-manet-aeroomni-autoconfiguration-services-for-manet-internetworking-00 Frederick Templin: Are you hearing me? Ronald: Yes. Fred: Okay, yes, I can present. This was originally intended to be a longer presentation but due to the current business climate that we're facing, I requested a reduced time slot to just cover the high points. So we'll just take five minutes to go through these materials. Fred: So in terms of a problem statement solution, summary, many routers support multi-hop forwarding within their local service areas Many routers may sometimes encounter intermittent or continuous areas internet gateway connectivity. During that time, it would be great if they could connect up to the global internet. So MANET routers will use a more multi-link local address locally within the MANET but they'll auto-configure globally unique addresses for internet networking purposes. MANET router auto-configuration services in internet working forward are based on a new architectural layer known as the adaptation layer. If you see the diagram on the right, you see the protocols stack layer there where the adaptation layer is a new layer in the architecture between the network layer and the data link layer. That adaptation layer is manifested by automatic extended route option and the overlay multi-link network interface to support all the necessary functions. Looking at the diagrams on the right here, we see three different use cases for MANET inter networking. The first in the upper right you see two nodes within a single MANET doing multi-hop forwarding over the MANET from peer peer to peer. The lower left, you see a node within a mobile ad hoc network connecting out to a node in the internet using a gateway that's shown in green here as a connectivity points of the global public internet. And then on the right you see a node in the internet being able to call into a node in MANET, again using this gateway. And this is all supported to through these AERO and OMNI multilink networking capabilities. Fred: Next chart. So in terms of next steps, each MANET router configures an OMNI interface and assigns them multi-link local address to the OMNI interface. The MANET Routers use AERO control messaging to invoke DHCPV6 auto-configuration services and obtain globally new addresses from the Internet gateways. The OMNI interface then supports IPV6 encapsulation for internet forwarding using the global unique addresses for peer-to-peer communications. And the MANET routes use the AERO and OMNI capabilities to try traverse Internet gateways and reach correspondence in both the Internet and other MANETs. So in the diagram, and in the right, you now see a use case where we have two separate MANET that are using the global public internet as transit. We have a node within a first MANET being able to call out across the internet through internet gateways to access the peer that's in the separate MANET. So what I've now shown is internet networking use cases for connecting manas to the global public internet and the final question was whether we want to take these documents on as working group items. That's the end of my presentation. Ron: Thank you. Rick Taylor: Do we not already have technology to do this within the IETF? I mean I could build this using SRV6. I am not sure I completely understand why the MANET has to have a completely independent IP addressing scheme and some sort of method... I can understand what you're doing, I don't understand why? Fred: It's to bring MANETs into the internet, and connect MANETs to the internet using the AERO and OMNI interface for inter-networking and for auto-configuration purposes. You may have been around, Rick, I don't know if you were around, back when we had the Auto-Conf Working Group. Rick: Yeah, I caught the tail end of it I would admit. It went on a while. Fred: Right. So, this is kind of picking up where the Auto-Conf left off. And really, this work has been in progress since the about Y2K time frame. It's been going on for about 20-some years And we're now at the point of maturation with these drafts that we can now provide an auto-configuration and networking service for connecting MANETs to the global public internet. These technologies do something that nothing else can do. Rik: But that is built on the assumption that the MANET has a complete opaque and independent addressing scheme from the public internet. And I wonder in the days of IPV6, whether that's the model we follow these days. Fred: Yeah. So with IPV6, Rick, when you have a MANET that, that's completely separate from the internet, has no connection points to the internet, it needs to have some way to configure IPV6 addresses that it can use internal to support the multi-hop forwarding with the MANET. And that's based on this new address type that I'm calling a multi-link local address or an MLA. The multi-link local addresses can be special purpose IPV6 addresses that are guaranteed to be unique through the birthday paradox of uniquely assigning an address that is either randomly chosen or assigned through an address adaptation service. But they're not necessarily rotable on the global internet. And so for that, when you do connect the MANET to the global public internet, you need to be able to get global unique addresses that are relative to that attachment point to the global public internet So there's two different address types, the multi-linked internet address that can be used within an isolated manet and the globally unique addresses that you get when you connect the MANET up to the internet Rick: Yeah, I'd love, someone who knows more about IPV6 ops than me to get a good review of this because, over the 25 years since this work started off, I think some of these problems have been solved and the idea of an entirely independent IPV6, well, IPV6-like MANET addressing sub-demand using a variant of SLAC or DHCPV6 to hand out something which is just not rootable. It kind of smacks of DHCPV4, well, IPV4 in general and we're bringing back NATs again. I have no horse in this race. I get what you're doing, I just personally don't get why, but thank you for answering. I need to go and read this draft, I think, is the answer. Thank you. Ron: And that may hold for more persons in this room, myself included. But in the interest of time, further technical comments that you may have please taken to the list. You were referencing the Auto-Conf Working Group, and the Auto-Conf Working Group was split off from the MANET Working Group because at the time the IESG felt the stuff that Auto-Conf was dealing with was not a routing area topic and therefore it had to happen in the INT area in a separate working group. Here the picture may be a bit more blurred including routing and non-routing stuff, the address configuration. But in any case, I don't think we can take this up as a working group item before we recharter But the point of having this presentation and at least the next one, now in this meeting, is to see if these are subjects that we should add to the draft charter that we already have. In that sense this is something to get familiarized with and then see if you feel that it would fit in a new charter and whether and to gauge whether there would be people to actually work on this. Kademlia-directed ID-based Routing Architecture (KIRA) (15 min) --------------------------------------------------------------- Ron: With that, I would like to go to the next presentation by Roland Bless and I will bring up to slides. https://datatracker.ietf.org/meeting/121/materials/slides-121-manet-kira-kademlia-directed-id-based-routing-architecture-00 Ronald Bless: I'm Ronald. Thanks for having me here. Last year I was presenting a routing area working group and Juliusz Chroboczek was at the mic and said, well, we have seen peer-to-peer routing in MANETs for a while and yeah, maybe come over to MANET. So, I'm just giving a brief presentation of Kira which stands for Kademlia directed ID based routing architecture and I refer to being a scalable zero-touch routing architecture. Ron B.: Next slide. The original goals of Kira is to provide receiving control playing connectivity in order to guarantee a robust network operation. We need that for various kinds of control, be as the end virtual infrastructure management AI-based control, what have you. So we try to guarantee the controllability of every network device and therefore you want to have this, let's say, resilient control plane fabric needs to be implemented in every device and therefore it's useful to be an IETF standard. So zero touch means no manual configuration and the addition you don't have any dependencies. Just the link layer connectivity needs to be there in order for it to work. There are some solutions out there, sure, but they are even not scalable. They are not fully zero touch or they are topology specific for data center, for example. Here I was not designed for mobile network networks, actually, it was not yet optimized for them, but it's zero touch and ID based. Ron B.: Next slide. What Kira basically provides is given some link layer topology (next slide) it provides connectivity on top of that. So as I said, for control plane it provides just the connectivity between all the resources. You can get back to any resource you want. Next. So on top of that, you typically run your whatever control applications. Could be SDN controller, it could be whatever 5G, 6G, SBA entity, the Kubernetes controller, PCE, whatever. So they will do their own control connections and protocols. We are just providing the connectivity Next slide. So what is different now with respect to other routing protocols? Kira puts, let's say, connectivity first and route efficiency second. Therefore, it's not directly suited for data planes. We're working on that, but right now, let's put it like this, that we have a separate data plane routing protocol like OSPF or ISIS, what have you. But you can go to the boxes and configure the necessary information like area information router IDs, assign IP addresses, whatever you using the connectivity that Kira provides. Ron B.: Next slide. So one use case is, for example, to use Kira for the 6G control plane, which also includes non-terrestrial networks like drones, satellites and so o.n So they are dynamic mobile. There is a use case also for Kira in that sense that you want to have all the resources that belong to a your infrastructure tied together by the same connectivity. We also envision Novetic networks, which are autonomous and also need a self-organizing control plane because there aren't, at least for certain periods of time, there are any infrastructure elements reachable. And also, scalability is an issue. As you know, there are millions of base stations sometimes just for a single provider like in China. Next slide. So, some features of KIRA, since Kademlia is in its name, Kademlia is used as ID-based overlay, which uses the XO metric as metric and as distance, so to say, in the number space. We use 112-bit node IDs and if you're familiar with the research, from more than 10 years ago, there was an approach like virtual ring routing which also had similar idea but it's actually less efficient than KIRA. We have small routing tables, so there are scaling logarithmically with a number of nodes which makes it scalable. But that implies stretch, naturally. So you know necessary or cannot always get shortest path routes to your destination we nevertheless care about efficiency so we use proximity neighbor selection and proximity routing in order to get still efficient routes. It has more or less two mechanisms: one of some initial path discovery so you can discover using a first path, which may be longer, connectivity to any node, and then get a more efficient later path that you can use for further communication in case you are able to afford that state. For dynamics, that's also a unique feature of KIRA, we have special path rediscovery mechanism with lack early approaches like featuring routing. Nice property is it's loop-free, even during convergence. We achieve that by using source routing for the routing protocol itself, but source routing is inefficient for small messages or longer paths So in order to be efficient for data packets, we use a path ID-based forwarding, which is a little bit similar like label switching. But we can actually pre-compute path IDs for certain set of notes. It is multipath capable and since we only have very few routing entries we can afford having multiple paths to the same destination. And we can also provide additional service on top like key value store for simple naming services and also topology discovery mechanisms. Ron B.: Next slide, please. So the architecture is, roughly like this. We have a routing tier that tries to find the connectivity using source routing. Below that, as just explained, we have the forwarding tier that use path ID-based forwarding. And we can also have additional services on top of the routing tier that makes use of the structure, for example, the routing table information that we have and topology discovery is very efficient. You only need to ask 4% of the nodes in order to get the full topology. And this is really fast, even for 100,000 notes. And, yeah, it's all based on IPv6. So we are forwarding IPV6 packets and the R2CAT, the routing protocol itself. also uses IPV6 between the directly adjacent nodes. Ron B.: Next slide. That's something that we recently tried. How does it work out of the box for MNAETs? So I'm not well-versed in that research, but this is a very simple scenario where we have 1,000 square meters, 100 nodes, random waypoint mobility model and speeds between one and 10 meter per seconds. And just without any, let's say, capability of detecting whether the links are there or not, I used just this kind of hello min and max intervals in order to detect whether there's connectivity or not and as you can see it's nearly in the range of other MANET protocols with respect to the delivery ratio around 95% or 94%. So this has no optimizations, so still optimizations may be possible. It's just out of the box. Ron B.: Next slide. So stretch wise, Juliusz was very skeptical about the stretch. And as you can see, the stretch is very low here So, stretch of one means short its path route, but we are not very far from that. And this is shown for the first packets. And also you can see that the stretch for the later packets is a little bit better. The overhead not optimized is just like it is 100 message per second. I think there's room for improvement. Ron B.: Next slide. How does it work in other topologies? These are fixed network topologies with 10,000 of nodes and you can see that the stretch is even in some cases or many cases better than Ripple in the ACP mode that is used in ANIMA so we can be it let's say fat tree or random topology power-log graphs, or even the internet has reasonable stretch values. Ron B.: Next slide. So I'm looking for support. There's a draft out there that is now, let's say, at a level where you can start implementing it. Please provide feedback. It's mainly submitted to the routing area working group. We have running code, so I hack some stuff at the hackatho.n Currently, we have a native routing demon for Linux, which provides zero touch IPV6 connect. The forwarding tier is realized using NF tables, so there is no new format that you need. We have an alternative EBBF implementation that is nearly complete, needs more testing and I really want more IETF expertise. So there's a site meeting set up for tomorrow evening at 7 in that small Wicklow Meeting Room 4 or remotely if you want. The agenda is that I give another intro for KIRA how it works a little bit then you can ask questions and we can find out whether there are possibilities for future collaboration. Thanks. Ron in't V.: Thank you Any? questions, comments? Ron B.: Yeah, that's a problem when I present that no feedback. Guys, if you think this is worth pursuing, then please Rick Taylor: I'll jump to the mic. Rick Taylor. I think this is really cool. I think this is full of great technology. I'm a big fan of Kademlia. I have been for years. I'm a big fan of DHTs as a way of building ad hoc networks. I've never spent enough time to work out whether it's possible and it looks like you have Lots of cool tech. I think it's great. I'm not offering to help, but I wish you all in luck with this. This looks really cool. Ron B.: So that's one of the things that I mean, I was not really directly, involved in the research that my colleagues did at the time, but I know the pitfalls and the other stuff. So I tried really to put the best of my knowledge together in order to get it still efficient routing and seems like it working quite nicely. Ron in't V.: Unfortunately, Juliusz doesn't seem to be present at the moment. Okay, thank you. So I'm here all week. So, yes we will have some offline discussion I think. Babel for IEEE 802.11 (Wi-Fi) Mesh (15 min) ------------------------------------------- Ron in't V.: Donald, are you ready? https://datatracker.ietf.org/meeting/121/materials/slides-121-manet-babel-for-ieee-80211-wi-fi-mesh-00 Donald Eastlake: Hi there, I'm Donald Eastlake, unaffiliated. I'm going to talk about the use of the BABEL routing protocol in 802.11 mesh. 802.11 is Wi-Fi. Donald: Next slide. This is what I'm going to talk about. BABEL is a distance vector kind of thing like RIP except it's got loop avoidance so it doesn't ever count to infinity or that sort of thing. And if you do that naively, then you can get starvation, but it has starvation avoidance on top of that so it reacts faster to topology changes and is basically rip-based but has the solutions to the problems with that. It's been proven to be very effective, particularly in networks with links of variable quality like radio links and mixed networks and things like that. Donald: [next slide] Okay, there's the standard now, it's RFC 8966. Did well, although it's a while ago, in the various battle mesh conrests in Europe. There's open source implementations, a Wikipedia article, and there's a technical paper at the bottom of this slide which gives an in-depth view. That one refers to the previous RFC 6126, which was a experimental RFC, now standards track. The differences aren't that large, but it gives much more detail. Donald: [next slide] So the original idea of 802.11 mesh from the other side was to do wireless backhaul so that access points could talk to each other and get back to a wired infrastructure. But it was fairly soon generalized into a really a peer-to-peer mesh where any of the mess stations can be access points if they wish to be, and it all sort of looks like a link to the outside. Donald: [nest slide] These mesh stations in Wi-Fi, they all send a mesh ID sort of like an SSID, but different, and there's a path selection protocol and a path metric. And if the stations match, they can peer together and form a mesh. And they have pair-wise keying, and there's also group keying for each station to the ones that it can see. And as I say, it appears to be a layer two link to the outside world. In the most general case a unicast packet has six addresses, the actual source, the mesh entry, the transmitter, the receiver, the mesh exit, and the destination. Donald: [next slide] We're going along pretty quick here, but if somebody has a question, or wants to interrupt, whatever. So the actual connection between a mesh station and outside network is called a mesh gate. So this shows one with three So you might say, well, what happens about loops? And the answer is, this is all in the 802 world. So it's assumed that the spanning tree or something equally good based on that is running in the outside network. So that solves that. And if you're interested how broadcast and multicast works, the stations send to everybody who can hear them, and the packet frames all have serial numbers and they keep track of what they've gotten recently so it basically floods and prunes and stuff gets everywhere. So, it uses a path selection protocol and link metric, and it was always realized that different meshes with different densities and station capability and number of radios per station and who knows what might require different path selection protocols and metrics so it was designed from the beginning so you could have different ones and you can even assign your own vendor specific [path selection protocol identiier]. And so the IETF can fabricate new ones using the IANA OUI if we feel like doing that. There's only one specified in the standard, which is called hybrid one wireless mesh protocol And it's based on AODV with some tree-based additions. And there were two early in the development of Wi-Fi mesh one the other one was called Radio Aware OLSR. There's always tremendous pressure to simplify things going through the standards process and it got pruned. Donald: [next slide] Like everything that comes along in Wi-Fi, mesh also has its, you know, power save for when stations can sleep and congestion management stuff and, you know, a few other gizmos. So it is no longer a separate document. It's been rolled into the base stand like they do, periodically. Current base standard is, 2020 there's a new one close to coming out but doesn't matter so you can go to the Get802 Standards page there and get your own copy of this massive document, which has the mesh scattered around in it. There is one section that is pretty focused but there's mesh provisions throughout. Donald: [next slide] The Wikipedia article lists some implementations. It was at least one point in Linux and BSD and an early version of the 802.11s draft was used in the one laptop for child, a not terribly successful project but... And there's lots of mesh products available for Wi-Fi that say they are mesh but as far as I'm aware, none of these actually use the standard mesh in there. And my purely personal opinion is that it hasn't been very successful for two reasons. At the time, there was no way in the 802.11 standard to really handle multiple radios per station. And, if you don't care much about performance, you're going to have a mesh with one radio per station. But given the interference and stuff, you really to get decent performance in a mesh, you need multiple radios. And secondly, I think that for many cases, the routing protocol they chose wasn't the best. So these have been essentially solved. There's 802.11be whose official name is Ultra-High Throughput, and it has defined a new thing, sort of above a station, although really they'll be physically all grouped together, called a multiple link device. But what it really kind of means, mostly is a multi-radio device despite that name. There's multi-link APs and multi-link non-AP stations. Although, it can be that the links are different sub-channels within the same piece of spectrum. So, the sense the multiple radio problem is solved and I think BABEL would be a very useful addition to Wi-Fi mesh. Donald: [next slide] So what exactly would you do if you were going to do BABEL for 802.11 mesh, say in the MANET working group? The big thing, of course, is to write an RFC that specifies how to use the BABEL routing method inside 8-11 mesh And it would be a path selection protocol We'd fabricate an ID for that. You could also specify how to use the BABEL default link metrics in 802.11. You could use that with some other 802.11 thing. And down at the way of the bottom [of this slide] in small type if you got all that done, you could define how to you the standard 802.11 link metric which is called the airtime link metric in BABEL. So I think the importance is proportional to the order and the size of the type here. Donald: [next slide] It would be basically easier to have BABEL working inside 802.11 mesh than it has been to develop the IP protocol because you don't need to carry IP addresses, protocol prefixes and lengths, you just use sets of MAC addresses. You don't need to have a separate router ID, the MAC address can serve as a router ID just fine. You don't need to worry about security. There are two other RFCs, standard-streck RFCs, that define security for BABEL, one of which provides just authentication, the other provides authentication and confidentiality. Because 802.11 has all its own security. You know the wireless 802.11 links sort of default to line speed encryption and so forth. And BABEL is very flexible on its link metric so it should work fine with the existing airtime mentor. We have explicit permission to do this I gave a presentation to 802.11 which is the first pointer there and they have sent a liaison to us in which, of course, they're don't want to say it's good or bad but they say, we have no objection. And in fact, they're very cooperative and I'm sure, for example, if somehow it turned out we needed another code point in some other 802.11 code space to do this efficiently, I have personal confidence that we would be able to get that allocated. They do have an Assigned Number Authority, but it's just inside 802.11. So we'd have to get the 802.11 work group to agree to it. Donald: [next slide] So somebody needs to write a draft. Or, of course, it will also be useful to be in charter, but maybe I should have put that on this slide too. Anyway, that's about it. Ron i't V,: Thank you, Donald. Oh, Lou, go ahead. Lou Berger: Lou Berger I'm trying to understand what you're expecting us to do here, other than saying "Hey, we could do this". Are you saying anything? Donald: Well, one thing I'm saying is that I support the text in the draft new charter that says that BABEL maintenance and development can be done in this working group. Lou: Okay. So is it BABEL or 802.11 with this specific version of BABEL? I mean... Donald: It's BABEL I mean, the way the routing protocol works would be the same. The thing is you have to say how to encode the BABEL message. Rick: I'm joining in the comments sorry, Don. I believe what Don is proposing is that in an updated charter, this working group can produce a what is effectively a profile of BABEL suitable for the 802.11 mesh environment. So using possibly the airtime metric, but that's a nice to have, but definitely dealing with MAC addresses, not IP at all addresses. And then you should just slot in, having looked at 802.11s ages ago, it should just slot in. Donald: BABEL has an address type data element and you'd have to allocate it new address type for MAC addresses. Lou: So as I read the slide, if you bring the slide up, that's great if you can't, and I'm missed, you can just, tell me I'm misreading it. But as I read, the slide, it said that we could do which one the one with the second last one I think it was. Donald: Very near the end. Lou: Yeah. The implication there is we could do anything we want on, no, the one that's said, yeah, this one [slide 14]. So I think what's not clear what's such act activity is here? and what the scope of what we might do really to what another SDO has to defined and I think that's the it's not clear how far you're opening the door here. So I think, I think we should be really, careful in anything we do related to another SDO's work to stay within our swim lane and not repeat some of the things we've done in the past of doing work on another SDO's protocol which goes well beyond what they may have envisioned or really into their domain. If we're modifying their protocol, that works should be an 802.11, not here. Donald: We basically have to figure out how to encode the BABEL routing messages inside 802.11 control frames. So it may end up being helpful in this regard that I was chair of 802.11 mesh for half of its existence. And I'm kind of thinking I might write this draft but go ahead. Lou: Then why not do it in 802.11? Donald: Because there's no energy there. Nobody cares about about mesh right now. The big locus of effort now is 802.11bn and whose official name is Ultra-High Reliability and of the 300 and some members of 80211, when you go to look at one of their parallel session 285 or so approximately or 280 or in that. So there were other activities happening there. So, I mean, I don't know if you're aware of that process of getting a new task group chartered and things for an amendment to 802.11? Lou: I think I know it a little bit, not a lot. My suggestion is, is to be very careful in any revised charter line to be very narrow scoped into things that are appropriate to be doing in the IETF and don't doing things that are appropriate in another SDO. Ron in't V.: Okay, point taken. Brian: Real quick question Don. Is there anything in all of this that wouldn't play well with the somewhat special things that are done in 802.11h? Halo. Dondald: I don't think so I guess H is the low frequency, the higher range stuff. Brian: Yeah, the low duty cycle 950 megahertz stuff. Ron in't V.: That's AH. Donald: Yeah, I'm not going to say anything about what exactly performance would be like and so on and so forth but I don't believe there's anything inherent different about that communication except that for timing and frequency and distance and all that kind of stuff. But it's all basically 802.11 is somewhat consistent. Ron in't V.: Very quick, Rick. Rick: I'll be very quick. Comment about, is this relevant within this SDO rather than IEEE? I believe and Don can correct me on this, that 802.11s as originally written very much borrowed AODV from this working group. Donald: Oh, yes. Rick: From this working group and was engineered such that, as you said, path selection algorithms can be plugged in. And it would make sense that this work group proposed or worked on yet another plug-in MANET routing program to work in this environment. So I think it's valid, and I'd support it. Donald: Thank You. New MANET Charter Discussions (10 min) -------------------------------------- https://datatracker.ietf.org/meeting/121/materials/slides-121-manet-draft-charter-text-01 Ron in't V.: Thanks. Which leaves us with just a bit of time to go over the draft charter text again but that's not a real disaster because we discussed this somewhat longer in Vancouver already. Actually, everything that has happened since is that I've incorporated the changes that were proposed by Juliusz Chroboczek. Meaning that it [the draft charter] now looks like this here. This is a general introduction to what this work group is about. There have been some minor changes here. This is mostly old charter texts still that has not changed. This is the DLEP specifics part where I have again applied a few of the suggested changes from Juliusz. Ron: This [AODVv2], we spent some time on in the Vancouver meeting and I'm still personally uncertain whether there will be any energy in the working group to pursue this and I think we need at least more justification for why we would be wanting to work on this and then yeah, we need at least the some people wanting to go do the work. Rick. Rick: Question for the chairs concerning AODVv2. So I've recently spoken to two of the authors on the MANET Working Group draft of AODVv2 and neither of them have had any communication with Charles Perkins for four-ish years. Have you managed to speak to Charlie about AODV? And it's an individual draft in dispatch or somewhere at the moment. I would support working on it, but it anyone spoken to Charlie about this or is this going to disappear into the void? Ron: Charlie has presented this when? Was it Brisbane or before? Donald: I've exchanged email with him. I encouraged him to produce a draft. I'm not sure I know all the people in communication paths and things involved, because it seemed like having, something upgraded to the current drafts formatting standards and things like that would be a useful starting place or things to work from. And, yeah, he's willing to do more work on the document but is not in a position where he can do implementation. Rick: Great. I was asking, does Charlie still have the energy to work on this? And is he still willing to do it? Donald: I think, yes, he indicated that at the time. Rick: Brilliant. Don Fedyk: I think the consensus was though that we don't have a lot, anybody really driving this like, you know, we have a few people willing to write drafts, but there was nobody that said that we're going to prototype it or use it So it's not strong support right now. Ron in't V.: Fred. please be very brief because we have less than four minutes left. Fred: Yeah, I can be brief. I just want to mention that the draft charter text does not talk about connecting MANETs up to the internet. Internet working for MANETs, I think, is a very important consideration, especially since we're in the Internet Engineering Task Force. And so what means for connecting the MANET up to the Internet and for Internet working with MANETs, I think, is something that needs to come into the charter. Ron in't V.: Would you be willing to provide a paragraph of text for that? Fred: I can do that. Ron in't V.: Okay, thank you. Okay, this is multicast. We've discussed this as well, changed some of the wording, edited the part about reverse path forwarding on Juliusz's request, I agree with it by the way. This is not interesting. Yeah there's something there about the IPPM. I think that's been overcome by events. And this is the list of potential work items a bit rationalized since last time. Yeah, it should be enough to keep us busy for a while if there are people to pick up some of these or all of these, hopefully. And now we have less than two minutes left. Any final comments on this by anyone? Online or in the room? Donald: Of course, you can all comment on the mailing list. Don Fedyk: That's what I was going to say. And there will be follow-up on the DLEP drafts shortly on the mailing list as well. Ron in't V.: Yes almost say it goes without saying that there's the mailing list for everything that falls off the edge of a one hour meeting. So, thank you all for attending either in person or remotely. Meeting adjourned. Don Fedyk: Yes, thank you all.