doc: Add V3 info #425

nejraselimovic · 2021-02-10T11:45:57Z

For supporting migration from V2 to V3, we addressed that there should be:

[x] a V3 info page (what is it, where to find it, reasons to migrate)
[x] a simplified guide on how to migrate from V2 to V3 -> WiP
[ ] FAQ page -> WiP

johanstokking · 2021-02-10T13:10:51Z

_content/the-things-stack-v3/migrate-to-v3.md

+---
+title: How do I migrate to The Things Stack V3?
+---


This this be filled in?

yes, I'm still working on the migration part and FAQ

@johanstokking Can you please spend some time to review this? I'm still left with FAQ, but that can be updated along the way with new questions. This was the idea:

info page - provide info about what V3 is, where to find it, why to migrate

migration page - unite the overall migration process in a single place on ttn.org/docs, link the relevant documentation so people know where to find more details

johanstokking · 2021-02-12T08:03:55Z

_content/the-things-stack-v3/migrate-to-v3.md

    var bytes = input.bytes;
-    var port = input.fport;
+    var port = input.fPort;
  return {


Wrong indentation here it seems

I think what suffices here is that the payload format has changed. Link to the new format.

The old format still works in V3, so to keep things as easy as possible here, don't ask to rewrite the payload codecs.

johanstokking · 2021-02-12T08:05:55Z

_content/the-things-stack-v3/migrate-to-v3.md

-# What to do with ABP end device?
+## What to do with ABP end device?
+
+If you are using an ABP device, that means your end device is still associated with the V2 `DevAddr`, so the Packet Broker will not be able to route its traffic to your V3 server if you have not connected your gateway to V3. In order to route this traffic correctly, follow the next steps to migrate your gateway to the V3 deployment.


"your V3 server" -> your V3 cluster
"the V3 deployment" -> the V3 cluster

Check other occurrences too

johanstokking · 2021-02-12T08:07:26Z

_content/the-things-stack-v3/migrate-to-v3.md

+
+If it was the public V2 deployment, and you are using The Things Stack v3.10 or higher, you may transfer the active device session as well - this means your device can continue working on The Things Stack V3 deployment without the need for a rejoin.
+
+If it was the private V2 deployment, devices that have the `DevAddr` that is out of the scope of the address block supported by The Things Stack V3 will have to perform a rejoin. 


For private V2 SaaS customers, we do make the DevAddr block available to The Things Stack Cloud. So that is going to work, also with ABP.

@johanstokking I found this here: https://www.thethingsindustries.com/docs/getting-started/migrating/migrating-from-v2/, so I guess this should be updated then. Btw, something is confusing me a bit, so I would be grateful if you would explain this shortly.

If you migrate an active OTAA session to V3, keys get deleted from V2 automatically, and the device doesn't have to perform a new join to V3. If you use --ttnv2.with-session=false flag, keys will stay untouched on V2, but then you have to manually prevent the device from joining V2 and your device has to do a new join to the V3 network

What confuses me is 1 session during ABP device lifetime -> what would --ttnv2.with-session=false flag mean in ABP case? Just that keys don't get deleted from V2 and you have to manually delete the device from V2 in order for it to work on V3? Is this flag even applicable to ABP?

I found this here: thethingsindustries.com/docs/getting-started/migrating/migrating-from-v2

I referred to the second paragraph, about the DevAddr scope. That is not covered in that doc, right?

What confuses me is 1 session during ABP device lifetime -> what would --ttnv2.with-session=false flag mean in ABP case? Just that keys don't get deleted from V2 and you have to manually delete the device from V2 in order for it to work on V3? Is this flag even applicable to ABP?

Yes. Indeed, not deleting the ABP session in V2 and creating it in V3 leads to errors as the session is then in two places, creating potential conflicts.

I found this here: thethingsindustries.com/docs/getting-started/migrating/migrating-from-v2

I referred to the second paragraph, about the DevAddr scope. That is not covered in that doc, right?

Actually, it is - second paragraph under Migrating active sessions.

Ah I see what you mean now, sorry. This:

When migrating from a private The Things Network Stack V2, devices that are outside of the DevAddr address block supported by The Things Stack Cloud will have to rejoin the network, otherwise The Things Stack will be unable to route their uplink and downlink traffic.

This indeed is not true and can be removed or rewritten as that we are making the same DevAddr range available in The Things Stack Cloud.

nejraselimovic · 2021-02-12T12:29:21Z

@johanstokking I processed your feedback
@htdvisser you might want to check this too

johanstokking

Great, let's get this merged and let's keep a close eye on community feedback to improve as-needed. This is already infinitely better than what we have today, great work.

nejraselimovic · 2021-02-12T14:41:26Z

Great, let's get this merged and let's keep a close eye on community feedback to improve as-needed. This is already infinitely better than what we have today, great work.

@htdvisser suggested we wait with publishing this until deploying nam and au1 is done. Should I wait or merge now, then update next week? I'm also still working on FAQ.

johanstokking · 2021-02-15T09:48:16Z

I'm OK with merging now.

nejraselimovic added the doc label Feb 10, 2021

nejraselimovic requested review from johanstokking and laurensslats February 10, 2021 11:45

nejraselimovic self-assigned this Feb 10, 2021

johanstokking reviewed Feb 10, 2021

View reviewed changes

johanstokking reviewed Feb 12, 2021

View reviewed changes

nejraselimovic requested a review from htdvisser February 12, 2021 12:28

johanstokking approved these changes Feb 12, 2021

View reviewed changes

htdvisser approved these changes Feb 15, 2021

View reviewed changes

doc: Add V3 info and migration guide

3d92a9b

nejraselimovic force-pushed the issue/add-v3-migration-support branch from 7f3ff98 to 3d92a9b Compare February 16, 2021 07:36

nejraselimovic merged commit c4e9a12 into master Feb 16, 2021


		If it was the public V2 deployment, and you are using The Things Stack v3.10 or higher, you may transfer the active device session as well - this means your device can continue working on The Things Stack V3 deployment without the need for a rejoin.

		If it was the private V2 deployment, devices that have the `DevAddr` that is out of the scope of the address block supported by The Things Stack V3 will have to perform a rejoin.

doc: Add V3 info #425

doc: Add V3 info #425

Uh oh!

Conversation

nejraselimovic commented Feb 10, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nejraselimovic commented Feb 12, 2021

Uh oh!

johanstokking left a comment

Choose a reason for hiding this comment

Uh oh!

nejraselimovic commented Feb 12, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

johanstokking commented Feb 15, 2021

Uh oh!

Uh oh!

nejraselimovic commented Feb 10, 2021 •

edited

Loading

nejraselimovic commented Feb 12, 2021 •

edited

Loading