Re: [Rift] RIFT protocol implementation

[Tony Przygienda <[e-mail]>]

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 <[e-mail]>
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
>
> On May 12, 2020, at 4:51 PM, Tony Przygienda <[e-mail]> 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 <[e-mail]>
> wrote:
>
>> 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 <
>> [e-mail]> 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
>>>
>>> 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]> 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]> <brunorijsman@gmail..com>
>>>> *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
>>>>
>>>>
>>> _______________________________________________
>>> RIFT mailing [e-mail]://www.ietf.org/mailman/listinfo/rift
>>>
>>>
>