Skip to main content

Minutes IETF117: manet: Wed 00:00
minutes-117-manet-202307260000-00

Meeting Minutes Mobile Ad-hoc Networks (manet) WG
Date and time 2023-07-26 00:00
Title Minutes IETF117: manet: Wed 00:00
State Active
Other versions markdown
Last updated 2023-08-18

minutes-117-manet-202307260000-00

IETF 117 MANET WG session agenda

When: Tuesday, July 25, 2023, Session IV, 17:00 - 18:00 PDT (Wednesday,
July 26, 0:00 - 1:00 UTC)

Where: Continental 8-9 + online

Meetecho: https://meetings.conf.meetecho.com/ietf117/?session=30663
Chat: https://zulip.ietf.org/#narrow/stream/manet
Notepad: https://notes.ietf.org/notes-ietf-117-manet

Chairs: Donald Eastlake, Don Fedyk, Ronald in 't Velt

Abbrevations:
cDE, DE: Donald Eastlake
cDF, DF: Don Fedyk
cRV, RV: Ronald in 't Velt
AW: Adam Wiethuechter (Notetaker)

Chairs' Introduction (5 min): cRV

Welcome all

Note Well, etc.

Note well, reach out if feel attacked, point to session materials (see
above). No initial complaints on agenda.

WG Status

MANET is about to recharter and BABEL is closing (1 doc remaining in
IESG review). BABEL will be merged with MANET and new BABEL items on the
MANET charter.

Combined meeting of ROLL/BABEL/MANET had a name suggestion - not
planning to take

For this reason Don Eastlake appointed as another chair (welcome,
wherever you are!).

Agenda bashing

No issues raised. Chairs already bashed.

Document status - chairs (5 min)

4 drafts with credit based flow control. Have been on WG for far too
long. Lou has revived before the cutoff for this meeting.

cRV has appointed himself sheppard and vows to get stuff done. Very
first write up on first document to be done. Sneak preview on the slide.

TSV ART early review.

Credit Ext. not part of the review pack and needs to be added for
review.

TSV ART asked for rational to be put in write up.

Chris Dearlove: we are at last stage of documents?

Yes. We have decided were ready due to little say on ML.

Next is RTGDIR review.

Wants TSVART review cleared before this.

Lou Berger: request that the RTGDIR be done. Been stable for years,
changes tiny. No need unless AD wants review after publication.

LB: its time. if there are nits that is what editor takes care of. If
you want to kill them fine.

Some individual drafts with PHY DLEP extension that are revived. Talked
to author about 6-7 weeks ago. Convinced of use with low capacity links.
Can use local parameters which are better than nothing with links.

One went with WG adoption call, no clear view on adoption. Agree with
cDF to send 3 documents to WG Adoption call.

One new I-D and invite David to the mic.

Presentation on potential new charter work item:

Sloppy Topology Updates for ad-hoc Routing Protocols (STURP) - (Zhe Lou,
20 min including discussion)
https://datatracker.ietf.org/doc/draft-lou-manet-sturp/

David Lou

Generic topology update mechanism to improve the updates for MANETs.
Intention to integrate into various RTG protocols.

Draft focuses on concepts.

Updates triggered by ongoing relations as long as they dont impact
existing services.

Topology updates may be partial rather than global.

Between reactive and proactive. Procative good for users but can be
slow.

Topology Hash and Sync Radius in HELLO message between neighbors.

Topology Hash is 32-bits of the local NITs.

Sync Radius 1-byte that indicates N hops share the same topology info.

Every node will have over topology info and view and that represented by
neighbor information table.

TIBD = Topology Information Database

Sync Radius calculation, check all neighbors and if all the same and
will be minimum of neighbors + 1.

How do we use Sync Radius? If you need to launch app from A to D see if
Sync Radius is okay to do that. Check hash is same or sync radius >= n-2
otherwise topo refresh

Rick Taylor: very interesting work. 1) if A,B,C triangle then how does
Sync Radius works?

When join resets.

RT: 2) you have a seq number, how do ensure that when two nodes join at
same time how to avoid old info after new info

Seq that self increments and start random. overwrite

Juliusz Chroboczek: this is to augment existing rtg protocols?

Yes

JC: so there already exists Routing Table and this augments it? Taking
two tables if they are correct and combining them to something that
makes sense if a very hard problem. ultimate goal it to make routing
table everything else is technical details.

How you calculate ...

JC: once you calculate table how do you combine with example OLSR
routing table and that needs to be clarified.

The way of calculation is to use existing one. Only update neighbor info
table and out of scope of text

Chrisopher Dearlove: i think we have routing protocol that extending
from olsr we dont start from here you ask what can be done better. there
are lot of olsr extensions that exist.

Yes. in email we agree, wrote in such a way how such a mechanism can
work and write them into specific protocol target accordingly.

CD: more than format is philosphy. you talk more about stable where
manets are more volitale.

cRV: continue on the list. thanks Chris, welcome back.

Presentation on potential new charter work item:

BABEL for IEEE 802.11 (Wi-Fi) Mesh - (Donald Eastlake, 15 min)

Formally chair of 802.11s (Mesh) group.

About babel: distrance-vector with mechanism for loop avoidance.
converges faster with a mix of quality links. RFC8966

Battlemesh contents. Open source implementations.

802.11s, original target was wireless backhaul

generalized to work peer to peer (not ap-to-ap). can appear as a link to
outside work. AP is othoganal to MP.

all stations sends out beacon with various items.

Mehs looks like later 2 link from outside.

can have up to 6 mac address, source, dest, mesh source and dst, ...

802.11s uses Path Selection Protocol for forwarding. differnt ones would
be suitable for other envirornments.

Standard HWMP (AODV with tree-based additions)

S rolled into 2020 standard, over 5000pages (send help). can get for
free with Get 802 program

What could we do?

  • Write RFC how to use BABEL in 802.11 mesh as PSP.
  • Or RFC how to use BABLE link metrics inside 802.11
  • or Ait Time link metric use in BABEL

BABLE as PSP would be very simple.

Explict persmission from 802.11 to do this. Presented in May 2023.
Generated liasion to IETF. IEEE will not stick its head out to say good
idea or not but no issue as was designed. Would be willing to grant
codepoints if needed.

Could be a separate thing, someone just needs to start writing!

Lou Berger: trouble getting in queue! interesting, why here?

BABEL owned by IETF, so would be here. Why not?

LB: sure expertise for control protocol is here, not wireless protocol.
got into trouble taking on dataplane from other SDOs.

Not forcing to work on it.

Alvaro: looked at sldies from 802.11. Why would 802.11 be interested?
Seems they were not. If we do this waht will IEEE do?

I think we would want someone to implement in development test mode for
802.11 which is doable. To do in IEEE would require more overhead to get
it added.

cRV: wil ltake up rest of hour...

Rick Taylor: no doubt BABEL work, no doubt 802.11 has hook, no doubt
..., no idea use case? Radio mfr says "i want to do this to make my
product better". No pressing industrial need for it.

Mesh would work better with BABEL

RT: agree, feels like build it and then they will come. Not a bad idea.

Rechartering discussion - all (15 min) cRV

4 minutes - lets go! (probably to list)

Look at last 3 chair slides.

Jim: came up in RTG WG, satelite routing requirements could fit under
MANET. suggested to talk with MANET chairs. Expect approach from RTG WG
chairs.

Alvaro: these are different satelite people! Try to recharter for last,
how long??? Setup interim meeting 6 weeks from now and get it done. Push
Lou's dcouments out!

Lou: lets not recharter till publish.

cRV: thought we like parallels? Thank you for coming.

Lou: nice shirts

cRV: not coordinated! Adjurned!

AOB - (time permitting)