Re: [fdt] [Rift] RIFT protocol implementation

[Tony Przygienda <[e-mail]>]

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 <[e-mail]>
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
>
>
> On May 14, 2020, at 10:34 AM, Tony Przygienda <[e-mail]> 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 <[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
>>>>
>>>
>