Repository : ssh://git@diktynna/doc
On branches: backup-redmine/2023-01-14,main
>---------------------------------------------------------------
commit 536eaa0c5147e3a4ed7bfac5cf6deb6b6d4bb7cf
Author: Linus L��ssing <linus.luessing(a)c0d3.blue>
Date: Mon Dec 26 15:06:13 2022 +0000
doc: batman-adv/Multicast-Packet-Type
>---------------------------------------------------------------
536eaa0c5147e3a4ed7bfac5cf6deb6b6d4bb7cf
batman-adv/Multicast-Packet-Type.textile | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/batman-adv/Multicast-Packet-Type.textile b/batman-adv/Multicast-Packet-Type.textile
index d48136c7..10dbd5f5 100644
--- a/batman-adv/Multicast-Packet-Type.textile
+++ b/batman-adv/Multicast-Packet-Type.textile
@@ -138,12 +138,16 @@ h3. -Fragmentation / MTUs:-
-> Workaround C): We require a 1280 bytes MTU on all hard interfaces and only then set the multicast packet type capability flag.
-h3. Adding a sequence number? / How to avoid loops with tracker marking later?
+h3. -Adding a sequence number? / How to avoid loops with tracker marking later?-
-When later implementing a split control <-> data plane as originally envisioned, by allowing to send a multicast packet with only the tracker TVLV, without data. And caching this information to fill a multicast routing table. And then allowing to send a multicast packet without the tracker TVLV afterwards, there is the following issue:
+-When later implementing a split control <-> data plane as originally envisioned, by allowing to send a multicast packet with only the tracker TVLV, without data. And caching this information to fill a multicast routing table. And then allowing to send a multicast packet without the tracker TVLV afterwards, there is the following issue:-
-When first a path is marked through the tracker TVLV, then paths change due to OGM updates. And then a tracker packet marks such new paths then the merger of both the old and newly tracker marked paths could create routing loops, as the old path is not automatically invalidated.
+-When first a path is marked through the tracker TVLV, then paths change due to OGM updates. And then a tracker packet marks such new paths then the merger of both the old and newly tracker marked paths could create routing loops, as the old path is not automatically invalidated.-
-Solution:
+-Solution:-
-Don't mark paths. Instead use the tracker TVLV to fill a cache with the mcast/dests lists and assign a hash to this information. Then later send the multicast data with a TVLV containing only this hash instead of the full mcast/dests list. Therefore a specific list of destinations is still maintained and routing decisions still happen on the go, loopfree, instead of trying to a maintain a loopfree, adjacent multicast routing table.
\ No newline at end of file
+-Don't mark paths. Instead use the tracker TVLV to fill a cache with the mcast/dests lists and assign a hash to this information. Then later send the multicast data with a TVLV containing only this hash instead of the full mcast/dests list. Therefore a specific list of destinations is still maintained and routing decisions still happen on the go, loopfree, instead of trying to a maintain a loopfree, adjacent multicast routing table.-
+
+---
+
+-> Don't add a sequence number, we don't need it now. And a new hashing/caching TVLV described above should work fine later.
\ No newline at end of file