Please configure regions

Things are moving fast in the mesh, again!

A new regions proposal came out of MeshCore Canada. We think all repeaters in the Quebec province should adopt it to reduce cross-region flooding. It is a phased proposal that, at first, will not have significant impact on any user except for multi-city traffic, as it will separate Quebec from Montreal, unless a region is used on messages.

Ottawa has already started deploying this and has already separated themselves from the Montreal mesh through this mechanism.

For a repeater in the city, in or around Montreal, please perform the following configuration:

region def yul|* qc|* onqc|* can|* na
region allowf *
region default yul
region save

Other configurations are required for repeaters in Quebec, and edge repeaters between the cities.

See below for further examples and explanations!

Picking the right configuration¶

Regions can be complicated, but the decision is pretty simple. It's a few questions to answer:

1. in which Meshmapper regions is the repeater? (for Montreal and suburbs, for example, it's yul, for Quebec it's yqb)
2. is the repeater relaying traffic with other regions? (for a repeater in Shawinigan connecting yul and yqb, or the YQB-Belair repeater in Québec, the answer is yes!)
3. if so, does the repeater need to carry traffic from other regions? (for example, a repeater in Trois-Rivières would probably want to carry both the yul and yqb regions)

The Phase 1: repeater setup of the MeshCore Canada proposal guides you through those steps pretty well, but we're going to spell out a few examples.

We assume you are running MeshCore 1.16 or later. If not, follow the proposal which has examples for older firmware.

This guide also assumes you have no prior region configured, which you can check by running the region command which should just return *^ F:

> region
*^ F

Montreal city repeater¶

This is the simplest configuration, shown in the introduction above, for a simple repeater in the city.

region def yul|* qc|* onqc|* can|* na
region allowf *
region default yul
region save

This does the following 4 things:

1. configure the repeater to relay traffic for the local region (yul), the wider Quebec area (qc), the Ontario-Quebec corridor (onqc), and the wider Canada (can) and North America (na) regions
2. still allow unscoped traffic (allowf *)
3. send adverts with the local region (default yul)
4. save the configuration

Quebec city repeater¶

This is similar to the above, but in Quebec city:

region def yqb|* qc|* onqc|* can|* na
region allowf *
region default yqb
region save

See above for an explanation: the only difference is it configures the repeater for yqb instead of yul.

This is the initial configuration that should be set on YQB-Belair while people start using regions on their companions in Quebec city.

Quebec city edge repeater¶

This is the configuration that should be applied to an edge repeater like YQB-Belair eventually:

region def yqb|* qc|* onqc|* can|* na
region denyf *
region default yqb
region save

We say eventually here because we understand that YQB-Belair is a key repeater in the city. The denyf * line would stop the repeater from relaying unscoped traffic, which could be very disruptive.

So, for now, start with the allowf * until people adopt regions more widely, then switch when you're confident it won't break things.

Shawinigan edge repeater¶

Similarly to the above Quebec city edge repeater, it might be best to start with a allowf * configuration that would relay unscoped traffic. But ultimately, a repeater relaying traffic right in the middle between the yul and yqb regions should have the following configuration:

region def yul|* yqb|* qc|* onqc|* can|* na
region denyf *
region default yqb
region save

The only difference with the Quebec edge repeater is the addition of the yul region to the region def line, which means the repeater will relay traffic for both yul and yqb.

Note that we're assuming the repeater considers itself part of the yqb region, but if it would be in yul, the only difference would be the default line which would read:

region default yul

And, again, the configuration above is rather aggressive and could be disruptive for users. Best start with allowf * and switch once the companions have adopted the regions.

Companions¶

For now, nothing changes for companions. All (or most!) repeaters in a region need to configure their regions before companions can start using them, because a repeater configured without regions will drop scoped packets!

The phase 2 of the proposal is currently scheduled for January 2027, but it's possible we might have to rush this sooner if we still have flooding problems.

In phase 2, companions start setting a default region (which is used for DMs) and attach a region to each channel (which we will document in our channels documentation.

This is one example of a channels setup, assuming you're in the yul region (otherwise replace yul with yqb for example):

Who?¶

Those settings have been tested by the following operators and repeaters:

• anarcat: YUL-Little-Italy, YUL-Poly, YUL-Plateau-Ouest-R1
• GrosTonyMobil: YUL Mont Lanaudière, GrosTony RPT2
• T MeshPocket: YUL-Tétreaultville
• VA2DG: VA2DGR, VE2TOW, VE2RSM
• Smog: YMX-J6Z, YMX-J6Y
• lavamind: YUL-Viauville
• zivior: YUL-LucienLallier
• MeshCourte: Villeray, Villeray-Nord

All have been setup in "city" mode unless otherwise noted.

Why?¶

This is solving a similar issue than the floods and loops proposal in that we're trying to limit the amount of traffic key repeaters need to carry.

Regions have already been deployed in Ottawa, which has effectively split the network unless we start scoping packets. So if we want to resume cross-regions communications, we must start using regions.

Setting up regions will also allow people to get more familiar with this tool: in some circumstances (for example, a remote village), it might be a useful mechanism to allow a community to talk locally without sending their messages across the entire mesh.

Questions?¶

What's phase 3?¶

There's a phase 1 and phase 2, what's phase 3?

Phase 3 is a last resort mechanism that we can use in a noisy city to limit hop counts for unscoped packets. This would be done with:

set flood.max.unscoped 3

It's a softer version than denyf * in that it still relays traffic for a few hops, but then stops.

Can I add more regions in there?¶

Can I add, say YUL, Yul or YOLO to the regions list in case people misspell?

Please don't! There are regions discovery mechanisms in MeshCore that make companions discover regions. Adding those extra regions will just confuse everyone and bring ambiguity as to what should actually be in use.

Feedback and comments¶

We welcome comments and feedback on this proposal through our regular contact points and the merge request on Codeberg.

This article is also available under the shorter URL https://lora.reseaulibre.ca/regions/ for sharing more easily on the mesh.