Re: [Rift] RIFT protocol implementation

[Leonardo Alberro Zimmermann <[e-mail]>]

Hello all,

We added a full decoding for the TIRE/TIDE and LIE messages. Thus, the 
RIFT C dissector supports full decode of all the RIFT packets.

Regards,
Leonardo

El 12/5/20 a las 19:46, Leonardo Alberro Zimmermann escribió:
>
> 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 
>> <[e-mail] <mailto:[e-mail]>> 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 <[e-mail]>
>>>     <mailto:[e-mail]>
>>>     *Date: *Wednesday, March 18, 2020 at 9:10 AM
>>>     *To: *Bruno Rijsman <[e-mail]>
>>>     <mailto:brunorijsman@gmail..com>
>>>     *Cc: *Antoni Przygienda <[e-mail]>
>>>     <mailto:[e-mail]>, Leonardo Alberro Zimmermann
>>>     <[e-mail]> <mailto:[e-mail]>,
>>>     "[e-mail]" <mailto:[e-mail]>
>>>     <[e-mail]> <mailto:[e-mail]>,
>>>     "[e-mail]" <mailto:[e-mail]>
>>>     <[e-mail]> <mailto:[e-mail]>,
>>>     Giuseppe Di Battista <[e-mail]>
>>>     <mailto:[e-mail]>
>>>     *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
>>>     [e-mail]  <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/rift
>>
>>
>> _______________________________________________
>> RIFT mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rift