Lorawan-stack: Configure routing policies

Created on 9 Feb 2021  ·  3Comments  ·  Source: TheThingsNetwork/lorawan-stack

Summary

Configure routing policies.

For listing available networks and tenants, we need https://github.com/packetbroker/iam/issues/2.

Why do we need this?

For networks to configure routing policies with other networks

What is already there? What do you see now?

This should currently be done with pbctl, but it would be nice to be able to configure routing policies via the CLI and Console.

What is missing? What do you want to see?

The ability to configure routing policies between the local Packet Broker network or tenant, and any other network or tenant.

How do you propose to implement this?

  • Add API to Packet Broker Agent for routing policy management
  • Implement CLI support
  • Implement Console support. Let's start with manually entering the NetID and tenant ID. With https://github.com/packetbroker/iam/issues/2, we can have a dropdown of public networks and tenants (but still manual entry must be possible)

How do you propose to test this?

Integration testing

Can you do this yourself and submit a Pull Request?

Can do API and CLI support.

@kschiffer please already think about UX. See linked pbctl commands to get an idea of what can be done.

console packet broker agent needux sizlarge ucli uweb
Source
picture johanstokking

Most helpful comment

@kschiffer please start thinking about the UX in the form of wireframes.

The API is designed. See https://github.com/TheThingsNetwork/lorawan-stack/pull/3912/files#diff-4371dadc483aa14e23af85a7baf0e1d57b6d0c67fcf203b94412e13b224cc541 and then especially those rpcs.

My idea is as follows:

  • Administrators can manage peering for their network. In The Things Stack, this is per deployment. In The Things Stack Cloud, this is per tenant. That is, no application or device level settings (just yet)
  • The configuration is technically two-fold: forwarder and home network configuration. Forwarders have gateway infrastructure, home networks have end devices. Most users will play either role, but technically we need to make a distinction here

The UI elements are:

  1. Top-level menu item for Packet Broker. My suggestion would be to use the term Packet Broker to push that brand. So the menu item would read Packet Broker and not peering
  2. In the Console overview page, show the status of Packet Broker (t.b.d., but for now whether the network has an active registration)
  3. The Packet Broker settings page. Here, the user can:

    • Register and deregister with Packet Broker, and see their registration info (/pba/registration bindings). When there is no registration (NotFound), disable all components on the page

    • Manage the forwarder routing policies. This is on two levels: the default settings (/pba/forwarder/default-policy bindings) and per-home network (/pba/forwarder/policies bindings) settings. To configure per home network, you can allow the user to select a home network from a list of all available networks (/pba/forwarde/home-networks binding)

    • View the routing policies that other forwarders set for this home network (/pba/home-network/policies binding)

There will be statistics in the future, but don't bother with that for now.

picture johanstokking on 12 Mar 2021
👍2

All 3 comments

@kschiffer please start thinking about the UX in the form of wireframes.

The API is designed. See https://github.com/TheThingsNetwork/lorawan-stack/pull/3912/files#diff-4371dadc483aa14e23af85a7baf0e1d57b6d0c67fcf203b94412e13b224cc541 and then especially those rpcs.

My idea is as follows:

  • Administrators can manage peering for their network. In The Things Stack, this is per deployment. In The Things Stack Cloud, this is per tenant. That is, no application or device level settings (just yet)
  • The configuration is technically two-fold: forwarder and home network configuration. Forwarders have gateway infrastructure, home networks have end devices. Most users will play either role, but technically we need to make a distinction here

The UI elements are:

  1. Top-level menu item for Packet Broker. My suggestion would be to use the term Packet Broker to push that brand. So the menu item would read Packet Broker and not peering
  2. In the Console overview page, show the status of Packet Broker (t.b.d., but for now whether the network has an active registration)
  3. The Packet Broker settings page. Here, the user can:

    • Register and deregister with Packet Broker, and see their registration info (/pba/registration bindings). When there is no registration (NotFound), disable all components on the page

    • Manage the forwarder routing policies. This is on two levels: the default settings (/pba/forwarder/default-policy bindings) and per-home network (/pba/forwarder/policies bindings) settings. To configure per home network, you can allow the user to select a home network from a list of all available networks (/pba/forwarde/home-networks binding)

    • View the routing policies that other forwarders set for this home network (/pba/home-network/policies binding)

There will be statistics in the future, but don't bother with that for now.

johanstokking picture johanstokking on 12 Mar 2021
👍2

This needs major API extensions so this is moved to 3.12.

johanstokking picture johanstokking on 14 Mar 2021

@kschiffer please coordinate UX implementation and triage

johanstokking picture johanstokking on 30 Mar 2021
👍1
Was this page helpful?
0 / 5 - 0 ratings

Related issues

bafonins picture bafonins  ·  5Comments
kschiffer picture kschiffer  ·  6Comments
kschiffer picture kschiffer  ·  7Comments
MatteMoveSRL picture MatteMoveSRL  ·  7Comments
rvolosatovs picture rvolosatovs  ·  9Comments