Manet Status PagesMobile Ad-hoc Networks (Active WG)
Rtg Area: Alia Atlas, Alvaro Retana, Deborah Brungard | 1997-Jun-12 —Chairs:
IETF-100 manet minutes
Session 2017-11-16 1810-1910: Orchard - Audio stream - manet chatroom
Open mic: Alvaro Retana: Concern about low numbers, and that the agenda is all DLEP. Other charter items but no progress being made. Should we move multicast work to PIM? Keep WG open for OLSR? Justin: DLEP in a different WG would be good, this WG would go into hiatus. No energy for multicast work at the moment. OLSRv2 maintenance. Alvaro: We need a place for OLSRv2 work as it's relatively new. Lou Berger: A bunch of issues not related to DLEP. Important to continue DLEP work, lost of people interested that wont come to IETF, counting on us to keep it moving. Don't understand putting it in it's own working group, it's the same people. Alvaro: Familiar with work in CCAMP and elsewhere that might be related? Rick: 3 quick points - 1) Stan Ratliff also very keen, not able to make it to IETF this time. 2) SMF. MBONED starting to look at multicast over radio. 3) Industry really want DLEP to happen. Alvaro: DLEP has to happen. Other synergies in IETF. Justin: Babel WG meeting is also happening now, and could use DLEP. It's similar work, so people have gone to that meeting. Alvaro: Changing the WG name to DLEP is one option, or to put it somewhere else. Babel are finishing the main draft. Other option is rtgwg, may get diluted or lost. Lou: Could move to CCAMP. Here we've had hugely productive meetings because so focused, would not get so much time in CCAMP. There is synergy though. LMP (?) is a similar protocol. We'd lose out on time spent on DLEP. Justin: Would like to try a joint session with CCAMP. Lou: Wait til extensions are done? Rick: They could take a while. The point of my presentation in open meeting was that DLEP has applicability outside MANET. Henning: We will have more extensions before the current ones are finished. Ronald: Concerned about mission creep with DLEP. Would like to see it used in MANET primarily. Hoping for the SMF work (Forwarding information base) to happen in MANET. Was not in a position to lead but hoping to help. Justin: We have progress on our end, software working, minor things written, problem is getting it released. Can't bring anything at this time. Ronald: Will be a research group starting next year that will be heavily interested, so keeping that work alive would be good. Alvaro: How about we have a joint meeting next time, and look at synergies? Don't want to stretch this too long if we have no other work. Do one more cycle, make some progress on these drafts. Around the time of the next meeting we'll make a decision on what to do with MANET. Lou: We will lose the smaller high-volume exchanges. That's a management call. Nice to have a small group that all care, rather than a large group where we only get a few minutes of discussion. CCAMP had a full session this time. As previous chair we used to have slots that were 8 minutes long. Alvaro: Need to figure out the logistics. We could have a joint session alongside their own session. Like the fact we are making progress, but this does have applications elsewhere and we might be losing out on that. If we need to move multicast out to PIM, we need to make some other decision. Justin: Moving multicast out - reservation is their focus wouldnt be on wireless. Alvaro: Interest there in almost the same topic. Rick: That was exactly what they said in their meeting, they were looking initially at 802.11 but really looking at the properties of the links. Real energy to get it done. Ronald: Also thinking about IPwave, currently concentrating on 1-hop, but might decide they need to look at multi-hop too. Alvaro: That could work. Lou: Is that a better candidate for a joint DLEP meeting. Alvaro: Worth exploring. Lou: From Henning...DLEP for L3 radios is the additional thing - do we have more feature creep beyond this? Ronald: Will come back to that later. Lou: Some of the extensions were already there at the start. Justin: Way forward is to look for a joint session, will talk with Alvaro (AD) and Stan (co-chair). Rick: Something has to change, not sure what. Yes this small group is really productive for DLEP at the moment. Lou: Do we do 2 experiments? Alvaro: Focus on DLEP as this is the active work. Henning: Multicast routing is hard - lack OS support. Joining PIM might be a way to tackle this. Flow related DLEP extensions - Lou Berger ----------------------------------------- 4 extensions, all been updated. MIT-LL DLEP code on GitHub along with Wireshark dissector plugin (links on slide) Latency Range: Should we make this generic? Last time, we said if we made it generic, we'd need a sub-field in the Data Item to identify what metric the range applies to. Makes sense to do a range on a per-metric basis (one extension for each) Rick: You have convinced me, but if there was a sub-field, we'd have a "metric range data item" and sub-code, there wouldn't be an explosion. Lou: How do you indicate support? Lou: Do we want nanosecond range or microsecond? Henning: What if we add a "Smoothed over time" extension - do we again have one extension for each metric type? Min/Max is statistic, and other statistics could be supplied, we have a type explosion if we define an extension for each. The TLV space and amount of RFCs will get quite large. Lou: We have 216 available. We need an extension for each. So even if we are not filling the TLV space we still need extensions. IF we need more stats, we should consider adding them to this draft. Justin: Seems over-engineering to design the way Henning has mentioned at this point. Trying to design one to solve all is unnecessary. Rick: The reason I changed my mind on this was you lead away from the DLEP model of timely information about changes "I can just tell you for the lifetime of this session, it's min x, max y, standard deviation s" rather than report real time values. Guidance on how to do this properly is important. Lou: Opinions on microseconds or nanoseconds? Rick: better to keep consistency with core DLEP Henning: We have enough bits that even if we use nanosecond values, the maximum is huge. Seen already sub micro-second values. We can afford to waste a few bytes. Lou: compelling point, look to chair. Justin: Anyone object vehemently? Rick: No but need clarification on use of microseconds in core. DLEP Multi-hop forwarding - Lou Berger -------------------------------------- Removal of Reserved field. Control plane based Pause - Lou Berger -------------------------------------- On a per DSCP basis, say "dont send", "start sending" Discussion on list was do we need both Pause and Credits? Rick: Whats the difference between Pause and Credit window with 1 token in it? Henning: Pause is already used in drivers. Lou: We're not talking about Ethernet pause. Lou: Different use cases, credits are not simple so people might prefer to implement Pause. Henning: Can we have description of how to implement pause with the credit TLVs? Lou: Proposal of how to make some of this common. A traffic classification data item. Made Pause slightly more complex but its nice if you are reading/implementing both that we have commonality. Rick: Really hoping you were going to do this. Do we want to talk about flow IDs in a separate doc that all the extensions can refer to? Lou: Would be fine with that, either approach works, let's sort technical details first. Henning: Pushing flow ID stuff out - DSCP might be protected? Want to assign DSCPs to queues. Lou: disagree, but related comment supports same conclusion - what if want to do traffic classification using other fields? We could certainly break this apart, we should decide how many documents at some point. CIDs will change to FIDs (flow IDs). Was hoping to discuss Slide 13 but out of time, supporting router limits. Rick: router telling modem what queues to configure should be out of scope - DLEP is not a management protocol. Modem should just inform. DLEP Link Identifiers - Rick Taylor ----------------------------------- DLEP currently requires contiguous L2 domain. There are increasing number of use cases where this is a problem. L3 radios, infrastructure access point. Proposed solution is a new identifier _alongside_ the MAC (prev draft replaced the MAC - bad idea). IDs are opaque, have no meaning. Lou: original proposal had variable length - very flexible. Suggest a max length. Or a per-session value for the length. Rick: Wanted to avoid negotiation. Let's argue on list. Lou: 32 bits isn't enough. Rick: Extension makes some L3 information mandatory, IP addresses and or Attached subnets. Lou: required? Rick: Are there use cases for LIDs for another non L3-use-case? Want adoption. Justin: Quick poll, looks like interest, will go to list.