Re: [Rift] RIFT protocol implementation

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 <tonysietf@gmail.com> 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 <brunorijsman@gmail.com <mailto:brunorijsman@gmail.com>> 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 <tonysietf@gmail.com <mailto:tonysietf@gmail.com>> 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 <tonysietf@gmail.com <mailto:tonysietf@gmail.com>> 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 <lalberro@fing.edu.uy <mailto:lalberro@fing.edu.uy>> 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
>> 