Re: [Rift] RIFT protocol implementation

[Tony Przygienda <[e-mail]>]

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]> 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]>
> <[e-mail]>
> *Date: *Wednesday, March 18, 2020 at 9:10 AM
> *To: *Bruno Rijsman <[e-mail]> <[e-mail]>
> *Cc: *Antoni Przygienda <[e-mail]> <[e-mail]>, Leonardo
> Alberro Zimmermann <[e-mail]> <[e-mail]>,
> "[e-mail]" <[e-mail]>
> <[e-mail]> <[e-mail]>,
> "[e-mail]" <[e-mail]>
> <[e-mail]> <[e-mail]>, Giuseppe Di
> Battista <[e-mail]>
> <[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 [e-mail]://www.ietf.org/mailman/listinfo/rift
>
>