Re: [Rift] What is being standardized in the base spec? (draft-ietf-rift-rift)

[Antoni Przygienda <[e-mail]>]

Oh, and for the “but I cannot spy with my little eye the bits on the wire and what they mean anymore” argument I heard couple times. Tcpdump for rift took minimum time and is long implemented already in open source (and yes, AFAIR the whole deser code is compiler out the thrift spec model) 😉 … Yes, it’s as much a fundamental change as programmers in the 80s getting used to the idea that you don’t look @ assembly code much anymore to make sure that the “C compiler is right” 😉


  *   Tony

From: Antoni Przygienda <[e-mail]>
Date: Thursday, 1 April 2021 at 23:23
To: Bruno Rijsman <[e-mail]>, Alvaro Retana <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Zhaohui Zhang <[e-mail]>
Subject: Re: What is being standardized in the base spec? (draft-ietf-rift-rift)
Resent from: <[e-mail]>
Resent to: <[e-mail]>, "Sharma, Alankar" <[e-mail]>, <[e-mail]>, <[e-mail]>, Dmitry Afanasiev <[e-mail]>
Resent date: Thursday, 1 April 2021 at 23:23

Since that may lead to more interesting discussions in IETF (like extending Yang to be the message format description 😉


  1.  What Bruno says is spot on (nothing unusual 😉 Thrift model is a very precise syntactic description of the information exchange (well, thrift is not, I’m fudging a bit, but it’s very close to what we need), since we cannot talk to each other without agreeing on syntax if we want to have interoperable implementations, we MUST make it normative. Akin to having subject before verb in English as rule to talk English to each other (well, analogy breaks down here, a good model is orthogonal, our verbal languages are highly redundant @ every level for reasons of lousy underlying mediums, people reading email while talking etc 😉
  2.  The semantics (and semiotics) of the syntactic model cannot be captured by a model or rather, the model would be implicitly containing syntactically correct but semantically non-provable statements (well, that goes deeply into Chomsky, de Saussure, Goedel and Wittgenstein so let’s stop here). So we use human language (which is already able to produce those properties but is common to the readers 😉 And bunch formal crutches like FSM 😉 The boundary of how much semantics has to be normative is of course what IETF makes a good living off, it’s not a clear cut thing, it’s a boundary of craft and art and RFC 2119 😉 One can always write more & @ certain point the doc is so big stuff starts contradict each other.

Now, why Thrift? I looked @ all the stuff @ hand when working on those things and couple of things made Thrift the outstanding candidate for packet format capture in protocols (but not necessarily for other things)


  1.  Very lightweight compared to XML. XML is not only very “verbiageous” 😉 but to get XML to describe packets one would really need XSD and the tooling gets heavy, encoding gets big, not exciting, not exciting
  2.  Thrift is _very_ precise syntax wise compared to all other modelling languages out-the-box. There is a very clear distinction between set and array e.g. and maps of objects onto objects are supported. Optional/Mandatory incl. defaults is well defined etc, etc. Yes, you can “model” grpc (and arguable grpc is more performant) but so you can JSON and guess whether you got a set or array and what a “0” really means. So you can do more ASCII typewriter alphabet-soup flags which we do today  😉
  3.  Thrift is supported across insane (no other word) variety of languages and has a huge community. Yes, it’s not that exciting anymore but the compiler stability, clean implementation is bar to none I saw. I run personally rift thrift models across 4 languages (and hacked the compiler for some of them to my liking 😉 and never had a hicc-up in ser/deser. Yes, performance varies based on language and the API generated internally but thrift sers/desers no matter what architecture/language or time of the day.
  4.  It has a very well implemented optional unknown support (and Bruno tested that ad nauseum 😉 which is extremely important for extensiblity.
  5.  It has a plethora of encoding schemes incl. binary compressed. Is it as small as hand-coded bit-squeezed fields. Nah, it isn’t. Could we go and optimize and IETF-super-compressed encoding? Yeah, we could. Is it light-weight enough to scale to serious heavy-lifting. Yepp, it is from lots benchmarking. Ser’ing & des’ing is so fast it does simply not matter in today’s world and the size is good enough to run sizeable routing protocols is what I found.  Now, should we standardize the encoding in rift? I don’t think so, thrift negotiates that and has well-set default, if we standardize our own then yeah, we probably should have specs saying “thrift MUST be encoded using UTF-8-2-yang-ietf-translation 😉” . Worth a working group, possibly but first discussions needs be settled whether IETF invents its own “yang packet format extensions”. As my 2c, I think it would be misguided, yang looks good for config/state/service maybe, not a thing for packet formats (well, but it could be possibly twisted to that assuming we write yang compiler support for a dozen languages which could take a couple years @ least)

As Bruno said, proof in the pudding, clean room implementation rift interop discovered zero (0) interop bugs/crashes/surprises in LIEs. And I don’t think we found any problems on syntax in  rest of it either except discussions about FSM & semantics sometimes as it should be.


  *   Tony

From: Bruno Rijsman <[e-mail]>
Date: Thursday, 1 April 2021 at 22:51
To: Alvaro Retana <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Zhaohui Zhang <[e-mail]>
Subject: Re: What is being standardized in the base spec? (draft-ietf-rift-rift)
Resent from: <[e-mail]>
Resent to: <[e-mail]>, "Sharma, Alankar" <[e-mail]>, <[e-mail]>, <[e-mail]>, Dmitry Afanasiev <[e-mail]>
Resent date: Thursday, 1 April 2021 at 22:51

[External Email. Be cautious of content]

Just to elaborate a bit more in OSI “presentation layer” terminology.

The Thrift model is the abstract syntax. It describes the format of messages in an abstract manner. It is the moral equivalent of ASN.1

The Thrift compiler<https://urldefense.com/v3/__https:/thrift.apache.org/__;!!NEt6yMaO-gk!TRQjlvUwhpqq0r5ds49ALQB6LdfjgNk5f-qCGuolo1gsFFA7fT0FJD2QYwLUfQ$> toolchain generates the following code (in Python, C++, C, Rust, or whatever language):

(a) The data structures in the chosen language to hold the decoded messages (Python classes, C++ classes, C structs, etc.). This is the local syntax.

(b) The procedures to encode and decode the data structures into serialized messages on the wire. The rules for serialization are specific in the Thrift binary protocol “specification”: https://github.com/apache/thrift/blob/master/doc/specs/thrift-binary-protocol.md.  These Thrift rules are the equivalent of the ASN.1 Basic Encoding Rules (BER) / Distinguished Encoding Rules (DER) / etc. The serialized messages on the wire are called the transfer syntax.

Side note: the two RIFT implementations that I am familiar with have been implemented in two very different programming languages and are able to exchange Thrift messages using the above toolchain without any problems.

All of the above machinery is only used to specify the syntax of messages.  The semantics of the messages and the procedures of the protocol are not (fully) described in the Thrift data model alone; instead they are described in the text of the RIFT specification in the form of human language and formal state machines.

— Bruno

On Apr 1, 2021, at 10:31 PM, Bruno Rijsman <[e-mail]<mailto:[e-mail]>> wrote:

As an independent implementor of RIFT, who implemented the protocol using only the specification and without any inside knowledge of any other implementations, I interpreted the document according to your option (a).

I my view, the Thrift model *is* the normative specification of the packets on the wire, and I cannot imagine the protocol being implemented without the Thrift toolchain.

— Bruno



On Apr 1, 2021, at 10:11 PM, Alvaro Retana <[e-mail]<mailto:[e-mail]>> wrote:

Dear WG:

I have started my review of the (very long) base spec [1] [2].  Thank
you to everyone involved!


As I read through the document and ask questions, many are answered
"in the schema."  Using the schema is ok; we had already talked about
it being Normative.  However, it makes me wonder, what are we
standardizing?  Bear with me as I explain.

(a) The WG can standardize the schema itself, just like the IETF works
on, for example, YANG modules:  the module *is* the standard and the
rest of the text in the RFC represents a high-level overview and other
general things (IANA and Security Considerations, for example).  If we
go this route, we're assuming that people will extract the schema from
the document and use it (again, similar to YANG modules) -- and we're
taking advantage of thrift-specific facilities and assumptions (that
don't have to be explicitly specified).

(b) The WG can standardize a protocol specification
(rfc2328/rfc4271/ISO10589 are all examples of that).  In this case,
the body contains the specification of the protocol's expected
behavior, and the schema can aid in that definition.  For example,
instead of traditional packet formats, the schema can be used to
define the fields and some of the behavior -- it can also be used as a
"reference implementation."  If we go this route, we're
assuming/expecting that people will write non-thrift implementations
of the protocol without explicit knowledge of any thrift-specific
facilities (any such assumption would have to be explicitly
specified).


The question to the WG, for which I would like the Chairs to guide the
discussion, is: What are we standardizing?  When the WG reviewed the
document, what were the assumptions?


FWIW, I have been assuming/expecting (b).  If the WG intends (a), that
is ok -- I can change my expectations.   We need to be in alignment.

Thanks!

Alvaro.


[1] https://mailarchive.ietf.org/arch/msg/rift/yTujeIBGVuYcQMgnpTvVN_qPW9Y/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/rift/yTujeIBGVuYcQMgnpTvVN_qPW9Y/__;!!NEt6yMaO-gk!TRQjlvUwhpqq0r5ds49ALQB6LdfjgNk5f-qCGuolo1gsFFA7fT0FJD3_8dqqWA$>

[2] https://mailarchive.ietf.org/arch/msg/rift/r_YVHdNgrwtt_0wPotml1FBHmyI/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/rift/r_YVHdNgrwtt_0wPotml1FBHmyI/__;!!NEt6yMaO-gk!TRQjlvUwhpqq0r5ds49ALQB6LdfjgNk5f-qCGuolo1gsFFA7fT0FJD11nS5iuA$>




Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only