Subject: Re: [Rift] RIFT protocol implementation

From: Leonardo Alberro Zimmermann <[email-masked]>
Date: Tue, 12 May 2020 19:46:56 -0300

Hello all,

regarding the development of a wireshark dissector for RIFT, we are 
happy to introduce you our work. It is available at 
https://gitlab.com/fing-mina/datacenters/rift-dissector

RIFT C dissector is a complete Wireshark dissector for decoding RIFT 
protocol. The code identifies all the RIFT packets and builds a complete 
dissection for the TIE ones. This dissector has been tested with the 
current implementations of RIFT.

Regards,
Leonardo

El 26/3/20 a las 13:23, Tony Przygienda escribió:
> Leonardo, that is a great project. Observe that depending on language 
> backend/thrift compiler different streams may represent the same 
> encoding so it's good to test it against more than one implementation. 
> We should get streams that has all possible LIEs and TIEs in it.
>
> If you run juniper standalone public package 
> https://www.juniper.net/us/en/dm/free-rift-trial/ you can easily build 
> a 2x2 yaml topology and just snoop on a UDP port. I suggest snooping a 
> v6/v4 links from a spine to a leaf. that will give you all the LIEs 
> and node TIEs and default prefixes. If you break a link via CLI you 
> will get disaggregation as well. If you struggle with that, ping me ...
>
> Having said that you can do all that with open source as well (but 
> observe we didn't pull open source to -11 draft yet which had some 
> schema changes albeit minor). you can pull the schema yourself with 
> Bruno's help or I'll get to it one of these days ;-) ...
>
> Architecturally, since RIFT will evolve and possibly move to newer 
> major schemas, I would suggest you provision for the possibility to 
> put into wireshark multiple schema files, basically you'd need to 
> compile multiple directories in differnt namespaces and use the 
> correct one depending on the major you found on packet envelope (you 
> can always use the newest minor you support on the major, they are 
> always compatible).
>
> --- tony
>
>
>
> On Thu, Mar 26, 2020 at 7:17 AM Leonardo Alberro Zimmermann 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi everyone,
>
>     as a part of this project we are developing a wireshark dissector
>     for RIFT. The dissection for the security envelope is ready and
>     tested. Now we are working on the Serialized RIFT Model Object
>     dissection and for preparing the testing we are looking for a
>     "known" trace, i.e we need a few packets and the exact values of
>     these fields in the Thrift model. So if anyone can help us we'll
>     be grateful.
>
>     Regards,
>     Leonardo.
>
>     El 18/3/20 a las 13:34, Antoni Przygienda escribió:
>>
>>     Forwarding the discussion to the rift ietf list for further
>>     exposure & since I generally think it will be possibly more
>>     productive in a wider forum. Roma Tre University is working on
>>     Bruno’s open source and there’s a bunch of interesting tools
>>     they’re developing as well as you can read below.
>>
>>     --- tony
>>
>>     *From: *Mariano Scazzariello <[email-masked]>
>>     <mailto:[email-masked]>
>>     *Date: *Wednesday, March 18, 2020 at 9:10 AM
>>     *To: *Bruno Rijsman <[email-masked]>
>>     <mailto:brunorijsman@gmail..com>
>>     *Cc: *Antoni Przygienda <[email-masked]>
>>     <mailto:[email-masked]>, Leonardo Alberro Zimmermann
>>     <[email-masked]> <mailto:[email-masked]>,
>>     "[email-masked]" <mailto:[email-masked]>
>>     <[email-masked]> <mailto:[email-masked]>,
>>     "[email-masked]" <mailto:[email-masked]>
>>     <[email-masked]> <mailto:[email-masked]>,
>>     Giuseppe Di Battista <[email-masked]>
>>     <mailto:[email-masked]>
>>     *Subject: *Re: RIFT protocol implementation
>>
>>     Hi everyone,
>>     thanks for the extremely detailed suggestions! I have a lot of
>>     stuff which I can use to work on the implementation. Also thanks
>>     Tony for giving me further useful tips.
>>
>>     Also, I'm happy that we agree on almost every implementation
>>     detail and I agree with your suggested variations (like the flag
>>     for the spf_run_direction method).
>>
>>     About point C, I did not write anything since it seems quite easy
>>     to extend the Thrift model. If I have any issues, I'll surely ask
>>     you for some help. I also wrote a point D (which is how to handle
>>     the negative disaggregation in the RIB/FIB when received), but I
>>     read the Pascal slides (I add the link
>>     <https://urldefense.com/v3/__https:/bitbucket.org/riftrfc/rift_draft/src/master/negative*20disaggregation.pptx__;JQ!!NEt6yMaO-gk!QBFQP3Ec6u0elEKgEFaAEndcjyQntJXvMg0h2TfAH6kn4JLUaMb3FOYpDQOltw$>
>>     here, so everyone can access them easily) and the steps used in
>>     that presentation are the same that I thought.
>>
>>     I still have some doubts about the special SPF run:
>>     *2) We will also need a new member field orig_neg_disagg_prefixes
>>     (once again of type set, I think) that contains the negatively
>>     disaggregated prefixes that are autonomously being originated
>>     based on the detection of fallen leafs based on the difference
>>     between the normal and special SPF run.*
>>     You are proposing to postpone the RIB/FIB update after the
>>     special SPF run (which can detect additional fallen leaf nodes).
>>     This is right,  but should this only occur on ToF nodes? If we
>>     consider a node X, which is not a ToF, that receives a negative
>>     disaggregation TIE, it should only add the prefix in the
>>     /prop_neg_disagg_prefixes /set and check if it received this
>>     prefix from all its parent nodes and propagate it if required.
>>     Then it should proceed to update its RIB/FIB, without running the
>>     special SPF. Am I right?
>>
>>     About the flooding oscillations, Tony writes "Your best
>>     protection is scaled, randomized tests". Here at Roma Tre
>>     University we developed a tool called Kathará
>>     <https://urldefense.com/v3/__https:/www.kathara.org/__;!!NEt6yMaO-gk!QBFQP3Ec6u0elEKgEFaAEndcjyQntJXvMg0h2TfAH6kn4JLUaMb3FOZujrrECA$>
>>     which is able to emulate network scenarios using Docker
>>     containers. Recently, we also developed a Fat Tree Generator,
>>     that automatically generates a fat tree topology starting from
>>     the fundamental parameters of a Fat Tree (K_LEAF, K_TOP and R)
>>     that can be run in Kathará. It also auto-configures the routing
>>     protocol on each node (of course, we also included the
>>     RIFT-Python implementation). So we can generate Fat Tree
>>     topologies of any size and run tests on it to verify functional
>>     and behavioral aspects (and also gather routing information such
>>     as PDU size and count). We are also developing a Fat Tree Test
>>     Framework (in collaboration with Leonardo and the team at UY
>>     university) which implements typical data center network
>>     scenarios (such as link failure, node failure, fallen leaf,
>>     partitioned fabric and so on) to run integration tests on it. For
>>     example, we can check if the routing table of a node is equal to
>>     the expected one after a failure (e.g. loss of a multipath or a
>>     prefix). With this tool we can surely run randomized tests (at
>>     any scale, since Kathará supports Kubernetes) to ensure that no
>>     flooding oscillations occur.
>>
>>     I agree to move the discussion on the RIFT WG mailing list. Maybe
>>     someone of you should introduce us and explain what we're doing.
>>
>>     Thanks everyone for your time,
>>     Mariano.
>>
>>
>>     _______________________________________________
>>     RIFT mailing list
>>     [email-masked]  <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/rift
>
>
> _______________________________________________
> RIFT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rift

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 12 May 2020 15:48:32 -0700

multiple people were looking JUST for this.

maybe next interim implementation experience. this was lighting fast ;-)

-- tony

On Tue, May 12, 2020 at 3:47 PM Leonardo Alberro Zimmermann <
[email-masked]> wrote:

> Hello all,
>
> regarding the development of a wireshark dissector for RIFT, we are happy
> to introduce you our work. It is available at
> backend/thrift compiler different streams may represent the same encoding
> so it's good to test it against more than one implementation. We should get
> streams that has all possible LIEs and TIEs in it.
>
> https://www.juniper.net/us/en/dm/free-rift-trial/ you can easily build a
> 2x2 yaml topology and just snoop on a UDP port. I suggest snooping a v6/v4
> links from a spine to a leaf. that will give you all the LIEs and node TIEs
> and default prefixes. If you break a link via CLI you will get
> disaggregation as well. If you struggle with that, ping me ...
>
> Having said that you can do all that with open source as well (but observe
> we didn't pull open source to -11 draft yet which had some schema changes
> albeit minor). you can pull the schema yourself with Bruno's help or I'll
> get to it one of these days ;-) ...
>
> Architecturally, since RIFT will evolve and possibly move to newer major
> schemas, I would suggest you provision for the possibility to put into
> wireshark multiple schema files, basically you'd need to compile multiple
> directories in differnt namespaces and use the correct one depending on the
> major you found on packet envelope (you can always use the newest minor you
> support on the major, they are always compatible).
>
> --- tony
>
>
>
> On Thu, Mar 26, 2020 at 7:17 AM Leonardo Alberro Zimmermann <
> [email-masked]> wrote:
>
>> Hi everyone,
>>
>> as a part of this project we are developing a wireshark dissector for
>> RIFT. The dissection for the security envelope is ready and tested. Now we
>> are working on the Serialized RIFT Model Object dissection and for
>> preparing the testing we are looking for a "known" trace, i.e we need a few
>> packets and the exact values of these fields in the Thrift model. So if
>> anyone can help us we'll be grateful.
>>
>> Regards,
>> Leonardo.
>> Forwarding the discussion to the rift ietf list for further exposure &
>> since I generally think it will be possibly more productive in a wider
>> forum. Roma Tre University is working on Bruno’s open source and there’s a
>> bunch of interesting tools they’re developing as well as you can read
>> below.
>>
>>
>>
>> --- tony
>>
>>
>>
>> <[email-masked]>
>> *To: *Bruno Rijsman <[email-masked]> <brunorijsman@gmail..com>
>> *Cc: *Antoni Przygienda <[email-masked]> <[email-masked]>, Leonardo
>> Alberro Zimmermann <[email-masked]> <[email-masked]>,
>> "[email-masked]" <[email-masked]>
>> <[email-masked]> <[email-masked]>,
>> "[email-masked]" <[email-masked]>
>> <[email-masked]> <[email-masked]>, Giuseppe Di
>> Battista <[email-masked]>
>> <[email-masked]>
>> thanks for the extremely detailed suggestions! I have a lot of stuff
>> which I can use to work on the implementation. Also thanks Tony for giving
>> me further useful tips.
>>
>> Also, I'm happy that we agree on almost every implementation detail and I
>> agree with your suggested variations (like the flag for the
>> spf_run_direction method).
>>
>> About point C, I did not write anything since it seems quite easy to
>> extend the Thrift model. If I have any issues, I'll surely ask you for some
>> help. I also wrote a point D (which is how to handle the negative
>> disaggregation in the RIB/FIB when received), but I read the Pascal slides
>> (I add the link
>> here, so everyone can access them easily) and the steps used in that
>> presentation are the same that I thought.
>>
>> *2) We will also need a new member field orig_neg_disagg_prefixes (once
>> again of type set, I think) that contains the negatively disaggregated
>> prefixes that are autonomously being originated based on the detection of
>> fallen leafs based on the difference between the normal and special SPF
>> run.*
>> You are proposing to postpone the RIB/FIB update after the special SPF
>> run (which can detect additional fallen leaf nodes). This is right,  but
>> should this only occur on ToF nodes? If we consider a node X, which is not
>> a ToF, that receives a negative disaggregation TIE, it should only add the
>> prefix in the *prop_neg_disagg_prefixes *set and check if it received
>> this prefix from all its parent nodes and propagate it if required. Then it
>> should proceed to update its RIB/FIB, without running the special SPF. Am I
>> right?
>>
>> About the flooding oscillations, Tony writes "Your best protection is
>> scaled, randomized tests". Here at Roma Tre University we developed a tool
>> called Kathará
>> which is able to emulate network scenarios using Docker containers.
>> Recently, we also developed a Fat Tree Generator, that automatically
>> generates a fat tree topology starting from the fundamental parameters of a
>> Fat Tree (K_LEAF, K_TOP and R) that can be run in Kathará. It also
>> auto-configures the routing protocol on each node (of course, we also
>> included the RIFT-Python implementation). So we can generate Fat Tree
>> topologies of any size and run tests on it to verify functional and
>> behavioral aspects (and also gather routing information such as PDU size
>> and count). We are also developing a Fat Tree Test Framework (in
>> collaboration with Leonardo and the team at UY university) which implements
>> typical data center network scenarios (such as link failure, node failure,
>> fallen leaf, partitioned fabric and so on) to run integration tests on it.
>> For example, we can check if the routing table of a node is equal to the
>> expected one after a failure (e.g. loss of a multipath or a prefix). With
>> this tool we can surely run randomized tests (at any scale, since Kathará
>> supports Kubernetes) to ensure that no flooding oscillations occur.
>>
>> I agree to move the discussion on the RIFT WG mailing list. Maybe someone
>> of you should introduce us and explain what we're doing.
>>
>> RIFT mailing [email-masked]://www.ietf.org/mailman/listinfo/rift
>>
>>
> RIFT mailing [email-masked]://www.ietf.org/mailman/listinfo/rift
>
>

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 12 May 2020 15:51:08 -0700

and quick question, why didn't you just push the binary into thrift backend
to deserialize? People may send compressed binary formats etc and the
encoding may change. Point of the modelling exercise

-- tony

On Tue, May 12, 2020 at 3:48 PM Tony Przygienda <[email-masked]> wrote:

>> observe we didn't pull open source to -11 draft yet which had some schema
>> changes albeit minor). you can pull the schema yourself with Bruno's help
>> or I'll get to it one of these days ;-) ...
>>
>>> Also, I'm happy that we agree on almost every implementation detail and
>>> I agree with your suggested variations (like the flag for the

---

From: Leonardo Alberro Zimmermann <[email-masked]>
Date: Wed, 13 May 2020 14:44:15 -0300

this is an approach that we were discussing recently, I think we take 
this way due to our goals (a functional disector of TIE packets in order 
to do some experiments with the Roma Tre team) but the rest of the team 
(cc) could correct me :)

Regards,
Leonardo

El 12/5/20 a las 19:51, Tony Przygienda escribió:
> and quick question, why didn't you just push the binary into thrift 
> backend to deserialize? People may send compressed binary formats etc 
> and the encoding may change. Point of the modelling exercise
>
> -- tony
>
>
> On Tue, May 12, 2020 at 3:48 PM Tony Przygienda <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Tue, May 12, 2020 at 3:47 PM Leonardo Alberro Zimmermann
>         regarding the development of a wireshark dissector for RIFT,
>         we are happy to introduce you our work. It is available at
>         RIFT C dissector is a complete Wireshark dissector for
>         decoding RIFT protocol. The code identifies all the RIFT
>         packets and builds a complete dissection for the TIE ones.
>         This dissector has been tested with the current
>         implementations of RIFT.
>
>         Regards,
>         Leonardo
>
>>         Leonardo, that is a great project. Observe that depending on
>>         language backend/thrift compiler different streams may
>>         represent the same encoding so it's good to test it against
>>         more than one implementation. We should get streams that has
>>         all possible LIEs and TIEs in it.
>>
>>         https://www.juniper.net/us/en/dm/free-rift-trial/ you can
>>         easily build a 2x2 yaml topology and just snoop on a UDP
>>         port. I suggest snooping a v6/v4 links from a spine to a
>>         leaf. that will give you all the LIEs and node TIEs and
>>         default prefixes. If you break a link via CLI you will get
>>         Having said that you can do all that with open source as well
>>         (but observe we didn't pull open source to -11 draft yet
>>         which had some schema changes albeit minor). you can pull the
>>         schema yourself with Bruno's help or I'll get to it one of
>>         these days ;-) ...
>>
>>         Architecturally, since RIFT will evolve and possibly move to
>>         newer major schemas, I would suggest you provision for the
>>         possibility to put into wireshark multiple schema files,
>>         basically you'd need to compile multiple directories in
>>         differnt namespaces and use the correct one depending on the
>>         major you found on packet envelope (you can always use the
>>         newest minor you support on the major, they are always
>>         compatible).
>>
>>         --- tony
>>
>>
>>
>>             as a part of this project we are developing a wireshark
>>             dissector for RIFT. The dissection for the security
>>             envelope is ready and tested. Now we are working on the
>>             Serialized RIFT Model Object dissection and for preparing
>>             the testing we are looking for a "known" trace, i.e we
>>             need a few packets and the exact values of these fields
>>             in the Thrift model. So if anyone can help us we'll be
>>             grateful.
>>
>>             Regards,
>>             Leonardo.
>>
>>>             Forwarding the discussion to the rift ietf list for
>>>             further exposure & since I generally think it will be
>>>             possibly more productive in a wider forum. Roma Tre
>>>             University is working on Bruno’s open source and there’s
>>>             a bunch of interesting tools they’re developing as well
>>>             as you can read below.
>>>
>>>             --- tony
>>>
>>>             <[email-masked]>
>>>             <mailto:[email-masked]>, Giuseppe Di Battista
>>>             thanks for the extremely detailed suggestions! I have a
>>>             lot of stuff which I can use to work on the
>>>             implementation. Also thanks Tony for giving me further
>>>             useful tips.
>>>
>>>             Also, I'm happy that we agree on almost every
>>>             implementation detail and I agree with your suggested
>>>             variations (like the flag for the spf_run_direction method).
>>>
>>>             About point C, I did not write anything since it seems
>>>             quite easy to extend the Thrift model. If I have any
>>>             issues, I'll surely ask you for some help. I also wrote
>>>             a point D (which is how to handle the negative
>>>             disaggregation in the RIB/FIB when received), but I read
>>>             the Pascal slides (I add the link
>>>             here, so everyone can access them easily) and the steps
>>>             used in that presentation are the same that I thought.
>>>
>>>             *2) We will also need a new member field
>>>             orig_neg_disagg_prefixes (once again of type set, I
>>>             think) that contains the negatively disaggregated
>>>             prefixes that are autonomously being originated based on
>>>             the detection of fallen leafs based on the difference
>>>             You are proposing to postpone the RIB/FIB update after
>>>             the special SPF run (which can detect additional fallen
>>>             leaf nodes). This is right,  but should this only occur
>>>             on ToF nodes? If we consider a node X, which is not a
>>>             ToF, that receives a negative disaggregation TIE, it
>>>             should only add the prefix in the
>>>             /prop_neg_disagg_prefixes /set and check if it received
>>>             this prefix from all its parent nodes and propagate it
>>>             if required. Then it should proceed to update its
>>>             RIB/FIB, without running the special SPF. Am I right?
>>>
>>>             protection is scaled, randomized tests". Here at Roma
>>>             Tre University we developed a tool called Kathará
>>>             containers. Recently, we also developed a Fat Tree
>>>             Generator, that automatically generates a fat tree
>>>             topology starting from the fundamental parameters of a
>>>             Fat Tree (K_LEAF, K_TOP and R) that can be run in
>>>             Kathará. It also auto-configures the routing protocol on
>>>             each node (of course, we also included the RIFT-Python
>>>             implementation). So we can generate Fat Tree topologies
>>>             of any size and run tests on it to verify functional and
>>>             behavioral aspects (and also gather routing information
>>>             such as PDU size and count). We are also developing a
>>>             Fat Tree Test Framework (in collaboration with Leonardo
>>>             and the team at UY university) which implements typical
>>>             data center network scenarios (such as link failure,
>>>             node failure, fallen leaf, partitioned fabric and so on)
>>>             to run integration tests on it. For example, we can
>>>             check if the routing table of a node is equal to the
>>>             expected one after a failure (e.g. loss of a multipath
>>>             or a prefix). With this tool we can surely run
>>>             randomized tests (at any scale, since Kathará supports
>>>             Kubernetes) to ensure that no flooding oscillations occur.
>>>
>>>             I agree to move the discussion on the RIFT WG mailing
>>>             list. Maybe someone of you should introduce us and
>>>             explain what we're doing.
>>>

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 13 May 2020 17:03:42 -0700

well, it makes most sense if you have something that can actually deser/ser
a thrift object into something a generic formatted in wireshark can put
out. that way there is prety much zilch manual code. The ser/deser in C++
for thrift is very good, also in python, I tried some other languages but
not C. In case of doubt ping Luca Deri in Parma pls, he's a dear old friend
from Labs times and one of the original wireshark authors AFAIK

-- tony

On Wed, May 13, 2020 at 10:44 AM Leonardo Alberro Zimmermann <
[email-masked]> wrote:

> this is an approach that we were discussing recently, I think we take this
> way due to our goals (a functional disector of TIE packets in order to do
> some experiments with the Roma Tre team) but the rest of the team (cc)
> could correct me :)
>
> Regards,
> Leonardo
> backend to deserialize? People may send compressed binary formats etc and
> the encoding may change. Point of the modelling exercise
>
> -- tony
>
>
>>> v6/v4 links from a spine to a leaf. that will give you all the LIEs and
>>> node TIEs and default prefixes. If you break a link via CLI you will get

---

From: Bruno Rijsman <[email-masked]>
Date: Thu, 14 May 2020 06:59:39 -0600

One issue with using the Thrift decoder generated by the Thrift compiler is that the user interface of Wireshark allows you to highlight certain fields in the decoded message and automatically highlights the corresponding bytes in the hexdump of the binary message. Thus the Thrift decoder used in Wireshark must (a) know the exact order in which the fields occurred in the binary message, which may not be the same order as in the model and (b) know which bytes in the binary message correspond to which fields in the decoded message.  As far as I know the code generated by the Thrift compiler currently does not generate that information. An interesting approach would be to enhance the Thrift C back-end to include that information.

— Bruno

> On May 12, 2020, at 4:51 PM, Tony Przygienda <[email-masked]> wrote:
> 
> and quick question, why didn't you just push the binary into thrift backend to deserialize? People may send compressed binary formats etc and the encoding may change. Point of the modelling exercise
> 
> -- tony 
> 
> 
> On Tue, May 12, 2020 at 3:48 PM Tony Przygienda <[email-masked] <mailto:[email-masked]>> wrote:
> On Tue, May 12, 2020 at 3:47 PM Leonardo Alberro Zimmermann <[email-masked] <mailto:[email-masked]>> wrote:
> Hello all,
> 
> regarding the development of a wireshark dissector for RIFT, we are happy to introduce you our work. It is available at https://gitlab.com/fing-mina/datacenters/rift-dissector <https://gitlab.com/fing-mina/datacenters/rift-dissector>
> RIFT C dissector is a complete Wireshark dissector for decoding RIFT protocol. The code identifies all the RIFT packets and builds a complete dissection for the TIE ones. This dissector has been tested with the current implementations of RIFT.
> 
> Regards,
> Leonardo
> 
>> Leonardo, that is a great project. Observe that depending on language backend/thrift compiler different streams may represent the same encoding so it's good to test it against more than one implementation. We should get streams that has all possible LIEs and TIEs in it. 
>> 
>> If you run juniper standalone public package https://www.juniper.net/us/en/dm/free-rift-trial/ <https://www.juniper.net/us/en/dm/free-rift-trial/> you can easily build a 2x2 yaml topology and just snoop on a UDP port. I suggest snooping a v6/v4 links from a spine to a leaf. that will give you all the LIEs and node TIEs and default prefixes. If you break a link via CLI you will get disaggregation as well. If you struggle with that, ping me ... 
>> 
>> Having said that you can do all that with open source as well (but observe we didn't pull open source to -11 draft yet which had some schema changes albeit minor). you can pull the schema yourself with Bruno's help or I'll get to it one of these days ;-) ... 
>> 
>> Architecturally, since RIFT will evolve and possibly move to newer major schemas, I would suggest you provision for the possibility to put into wireshark multiple schema files, basically you'd need to compile multiple directories in differnt namespaces and use the correct one depending on the major you found on packet envelope (you can always use the newest minor you support on the major, they are always compatible). 
>> 
>> --- tony 
>> 
>> 
>> 
>> On Thu, Mar 26, 2020 at 7:17 AM Leonardo Alberro Zimmermann <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi everyone,
>> 
>> as a part of this project we are developing a wireshark dissector for RIFT. The dissection for the security envelope is ready and tested. Now we are working on the Serialized RIFT Model Object dissection and for preparing the testing we are looking for a "known" trace, i.e we need a few packets and the exact values of these fields in the Thrift model. So if anyone can help us we'll be grateful.
>> 
>> Regards,
>> Leonardo.
>> 
>>> Forwarding the discussion to the rift ietf list for further exposure & since I generally think it will be possibly more productive in a wider forum. Roma Tre University is working on Bruno’s open source and there’s a bunch of interesting tools they’re developing as well as you can read below.
>>> 
>>>  
>>> --- tony
>>> 
>>>  
>>> From: Mariano Scazzariello <[email-masked]> <mailto:[email-masked]>
>>> Date: Wednesday, March 18, 2020 at 9:10 AM
>>> To: Bruno Rijsman <[email-masked]> <mailto:brunorijsman@gmail..com>
>>> Cc: Antoni Przygienda <[email-masked]> <mailto:[email-masked]>, Leonardo Alberro Zimmermann <[email-masked]> <mailto:[email-masked]>, "[email-masked]" <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>,"[email-masked]" <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>, Giuseppe Di Battista <[email-masked]> <mailto:[email-masked]>
>>> Subject: Re: RIFT protocol implementation
>>> 
>>>  
>>> Hi everyone,
>>> thanks for the extremely detailed suggestions! I have a lot of stuff which I can use to work on the implementation. Also thanks Tony for giving me further useful tips.
>>> 
>>> Also, I'm happy that we agree on almost every implementation detail and I agree with your suggested variations (like the flag for the spf_run_direction method).
>>> 
>>> About point C, I did not write anything since it seems quite easy to extend the Thrift model. If I have any issues, I'll surely ask you for some help. I also wrote a point D (which is how to handle the negative disaggregation in the RIB/FIB when received), but I read the Pascal slides (I add the link <https://urldefense.com/v3/__https:/bitbucket.org/riftrfc/rift_draft/src/master/negative*20disaggregation.pptx__;JQ!!NEt6yMaO-gk!QBFQP3Ec6u0elEKgEFaAEndcjyQntJXvMg0h2TfAH6kn4JLUaMb3FOYpDQOltw$> here, so everyone can access them easily) and the steps used in that presentation are the same that I thought.
>>> 
>>> 2) We will also need a new member field orig_neg_disagg_prefixes (once again of type set, I think) that contains the negatively disaggregated prefixes that are autonomously being originated based on the detection of fallen leafs based on the difference between the normal and special SPF run. 
>>> You are proposing to postpone the RIB/FIB update after the special SPF run (which can detect additional fallen leaf nodes). This is right,  but should this only occur on ToF nodes? If we consider a node X, which is not a ToF, that receives a negative disaggregation TIE, it should only add the prefix in the prop_neg_disagg_prefixes set and check if it received this prefix from all its parent nodes and propagate it if required. Then it should proceed to update its RIB/FIB, without running the special SPF. Am I right?
>>> 
>>> About the flooding oscillations, Tony writes "Your best protection is scaled, randomized tests". Here at Roma Tre University we developed a tool called Kathará <https://urldefense.com/v3/__https:/www.kathara.org/__;!!NEt6yMaO-gk!QBFQP3Ec6u0elEKgEFaAEndcjyQntJXvMg0h2TfAH6kn4JLUaMb3FOZujrrECA$> which is able to emulate network scenarios using Docker containers. Recently, we also developed a Fat Tree Generator, that automatically generates a fat tree topology starting from the fundamental parameters of a Fat Tree (K_LEAF, K_TOP and R) that can be run in Kathará. It also auto-configures the routing protocol on each node (of course, we also included the RIFT-Python implementation). So we can generate Fat Tree topologies of any size and run tests on it to verify functional and behavioral aspects (and also gather routing information such as PDU size and count). We are also developing a Fat Tree Test Framework (in collaboration with Leonardo and the team at UY university) which implements typical data center network scenarios (such as link failure, node failure, fallen leaf, partitioned fabric and so on) to run integration tests on it. For example, we can check if the routing table of a node is equal to the expected one after a failure (e.g. loss of a multipath or a prefix). With this tool we can surely run randomized tests (at any scale, since Kathará supports Kubernetes) to ensure that no flooding oscillations occur.
>>> 
>>> I agree to move the discussion on the RIFT WG mailing list. Maybe someone of you should introduce us and explain what we're doing.
>>> 
>>> https://www.ietf.org/mailman/listinfo/rift <https://www.ietf.org/mailman/listinfo/rift>
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/rift <https://www.ietf.org/mailman/listinfo/rift>

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 14 May 2020 09:34:40 -0700

That runs in a sense completely counter a model based  encoding (don't
forget, thrift can run binary compressed messages as well, so how will you
offset that ;-)  But as I said, I didn't look @ the decode/encode too
closely, especially not in the C code.

Also, you'll have other effects like certain encoders omitting required
with default values if not set since it's in a sense "implied" for the
decoder.

We do break fairly new ground here ;-) but I think over time the benefits
of model based encoding/decoding will start influence other routing
protocols (there are other types of protocols running today that are fully
model based on encoding) given the advantages we were seeing in RIFT

-- tony

On Thu, May 14, 2020 at 5:59 AM Bruno Rijsman <[email-masked]>
wrote:

> One issue with using the Thrift decoder generated by the Thrift compiler
> is that the user interface of Wireshark allows you to highlight certain
> fields in the decoded message and automatically highlights the
> corresponding bytes in the hexdump of the binary message. Thus the Thrift
> decoder used in Wireshark must (a) know the exact order in which the fields
> occurred in the binary message, which may not be the same order as in the
> model and (b) know which bytes in the binary message correspond to which
> fields in the decoded message.  As far as I know the code generated by the
> Thrift compiler currently does not generate that information. An
> interesting approach would be to enhance the Thrift C back-end to include
> that information.
>
> — Bruno
>

---

From: Bruno Rijsman <[email-masked]>
Date: Thu, 14 May 2020 10:49:26 -0600

I am not disagreeing with you, Tony. Having to hand-craft a RIFT decoder for Wireshark stinks to high heaven. It would be infinitely better if we could use the message decoding C code that is generated by the Thrift-C compiler.

I think we are discovering some new requirements for model-based routing protocols that are new relative to the original use case of model-based APIs.

And we are discovering that those new requirements are not well supported by existing compilers (Thrift or otherwise).

I always had the urge to write an Internet-Draft on the topic of using Thrift as a modeling language for RIFT (what worked well, what didn’t work well, etc.) but I never got around to doing it.

Such a draft would be useful input for the formal languages BOF (WG?) https://www.ietf.org/mailman/listinfo/fdt <https://www.ietf.org/mailman/listinfo/fdt>

— Bruno

> On May 14, 2020, at 10:34 AM, Tony Przygienda <[email-masked]> wrote:
> 
> That runs in a sense completely counter a model based  encoding (don't forget, thrift can run binary compressed messages as well, so how will you offset that ;-)  But as I said, I didn't look @ the decode/encode too closely, especially not in the C code. 
> 
> Also, you'll have other effects like certain encoders omitting required with default values if not set since it's in a sense "implied" for the decoder. 
> 
> We do break fairly new ground here ;-) but I think over time the benefits of model based encoding/decoding will start influence other routing protocols (there are other types of protocols running today that are fully model based on encoding) given the advantages we were seeing in RIFT
> 
> -- tony 
> 
> On Thu, May 14, 2020 at 5:59 AM Bruno Rijsman <[email-masked] <mailto:[email-masked]>> wrote:
>> On May 12, 2020, at 4:51 PM, Tony Przygienda <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 14 May 2020 11:05:16 -0700

1. count me in on the draft if you put in the main work ;-)
2. my experience with thrift (apache) community have been very good. they
listen, they let you upstream. professional folks. I don't think they'll be
averse to what you suggest (index annotation on the decoder on the elements)
3. I was listening into the formal language stuff since a while but they
are holding interims @ 4AM PDT so I was out ;-)

-- tony

On Thu, May 14, 2020 at 9:49 AM Bruno Rijsman <[email-masked]>
wrote:

> I am not disagreeing with you, Tony. Having to hand-craft a RIFT decoder
> for Wireshark stinks to high heaven. It would be infinitely better if we
> could use the message decoding C code that is generated by the Thrift-C
> compiler.
>
> I think we are discovering some new requirements for model-based routing
> protocols that are new relative to the original use case of model-based
> APIs.
>
> And we are discovering that those new requirements are not well supported
> by existing compilers (Thrift or otherwise).
>
> I always had the urge to write an Internet-Draft on the topic of using
> Thrift as a modeling language for RIFT (what worked well, what didn’t work
> well, etc.) but I never got around to doing it.
>
> Such a draft would be useful input for the formal languages BOF (WG?)
> https://www.ietf.org/mailman/listinfo/fdt
>
> — Bruno
>
>