Subject: Re: [Rift] kicking off the charter discussion

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Jan 2018 23:07:34 -0000

Hi,
 
I joined this list a little late to have a neat head of thread to respond to, but here's a response to Alvaro's copy to routing-discussion.
 
The charter text looks water-tight to me and I'd like to see this WG formed so that the whole community can work on RIFT.
 
Maybe s/prominence/popularity/ 
 
There is a problem with the indentation in the deliverables...
OLD
- A Standards Track specification based on draft-przygienda-rift. The document will include:
 
  - an Implementation Status section as described in RFC 7942
  - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed
  - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.).
  - A YANG module focused on configuration of protocol instances
  - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies
  - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification.
NEW
- A Standards Track specification based on draft-przygienda-rift. The document will include:
      - an Implementation Status section as described in RFC 7942
      - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed
       - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.).
  - A YANG module focused on configuration of protocol instances
  - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies
  - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification.
END
 
Cheers,
Adrian

From: rtgwg [mailto:[email-masked]] On Behalf Of Alvaro Retana
Sent: 06 January 2018 03:25
To: [email-masked]; [email-masked]
Subject: Fwd: [Rift] kicking off the charter discussion
 
FYI..
 
If you are interested in this topic, please make comments and send feedback on the [email-masked] list.
 
Thanks!
 
Alvaro.
 
On January 5, 2018 at 3:03:25 AM, Alia Atlas ([email-masked]) wrote:
Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG charters with Alvaro.  Here is what we have so far.  Comments and improvements would be most welcome. 
 
================
Routing in Fat Trees (RIFT)

Clos and Fat-Tree topologies have gained prominence in data center networks as a result of a trend towards centralized data center network architectures that may deliver computation and storage services.
 
The Routing in Fat Trees (RIFT) protocol addresses the demands of routing in Clos and Fat-Tree networks via a mixture of both link-state and distance-vector techniques colloquially described as 'link-state towards the spine and distance vector towards the leafs'.  RIFT uses this hybrid approach to focus on networks with regular topologies with a high degree of connectivity, a defined directionality, and large scale.

The RIFT Working Group will work on a standards track specification of a specialized, dynamic routing protocol for Clos and fat-tree network topologies. The protocol will:

- deal with automatic construction of fat-tree topologies based on detection of links,
- minimize the amount of routing state held at each topology level,
- automatically prune topology distribution exchanges to a sufficient subset of links,
- support automatic disaggregation of prefixes on link and node failures to prevent black-holing and suboptimal routing,
- allow traffic steering and re-routing policies,
- and provide mechanisms to synchronize a limited key-value data-store that can be used after protocol convergence.

It is important that nodes participating in the protocol should need only very light configuration and should be able to join a network as leaf nodes simply by connecting to the network using default configuration.

The protocol must support IPv6 and should also support IPv4.

The Working Group may establish additional requirements to constrain and inform their work.

The RIFT Working Group is chartered for the following list of items:

- A Standards Track specification based on draft-przygienda-rift. The document will include:

  - an Implementation Status section as described in RFC 7942
  - an Operational Considerations section to explain how the protocol is configured, deployed, and diagnosed
  - Security and Privacy Considerations, although this material may refer to a separate Threat Analysis document (q.v.).
  - A YANG module focused on configuration of protocol instances
  - An Applicability Statement that describes how to deploy and configure the protocol in networks with different topologies
  - A Security Threat Analysis document that describes the attack vectors and mitigations that shall be sent for publication at the same time as the protocol specification.

Milestones

  Feb 2018 Adopt a protocol specification document
  Feb 2019 Submit protocol specification to IESG for publication
  Feb 2019 Submit Threat Analysis to IESG for publication
  Apr 2019 Submit YANG module to IESG for publication
  Apr 2019 Submit Applicability Statement to IESG for publication 
============
Thanks,
Alia
_______________________________________________ 
Rift mailing list 
[email-masked] 
https://www.ietf.org/mailman/listinfo/rift

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Jan 2018 18:23:48 -0500

I haven't commented because this seemed clear.

Sure, folks can argue that we don't need this.  We can just fine-tune 
existing things.  And we will.

Even so, this seems potentially very useful.  And explorse a part of the 
space we do not ahve a lot of experience engineering.  In a bounded fashion.

Seems like it is worth doing to me.
Yours,
Joel

On 1/5/18 10:24 PM, Alvaro Retana wrote:
> FYI..
> 
> If you are interested in this topic, please make comments and send 
> feedback on the [email-masked] <mailto:[email-masked]> list.
> 
> Thanks!
> 
> Alvaro.
> 
> On January 5, 2018 at 3:03:25 AM, Alia Atlas ([email-masked] 
> <mailto:[email-masked]>) wrote:
> 
>> Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT 
>> WG charters with Alvaro.  Here is what we have so far.  Comments and 
>> improvements would be most welcome.
>>
>> ================
>> Clos and Fat-Tree topologies have gained prominence in data center 
>> networks as a result of a trend towards centralized data center 
>> network architectures that may deliver computation and storage services.
>>
>> The Routing in Fat Trees (RIFT) protocol addresses the demands of 
>> routing in Clos and Fat-Tree networks via a mixture of both link-state 
>> and distance-vector techniques colloquially described as 'link-state 
>> towards the spine and distance vector towards the leafs'.  RIFT uses 
>> this hybrid approach to focus on networks with regular topologies with 
>> a high degree of connectivity, a defined directionality, and large scale.
>>
>> The RIFT Working Group will work on a standards track specification of 
>> a specialized, dynamic routing protocol for Clos and fat-tree network 
>> topologies. The protocol will:
>>
>> - support automatic disaggregation of prefixes on link and node 
>> failures to prevent black-holing and suboptimal routing,
>> - and provide mechanisms to synchronize a limited key-value data-store 
>> that can be used after protocol convergence.
>>
>> It is important that nodes participating in the protocol should need 
>> only very light configuration and should be able to join a network as 
>> leaf nodes simply by connecting to the network using default 
>> configuration.
>>
>>   - Security and Privacy Considerations, although this material may 
>> refer to a separate Threat Analysis document (q.v.).
>>   - An Applicability Statement that describes how to deploy and 
>> configure the protocol in networks with different topologies
>>   - A Security Threat Analysis document that describes the attack 
>> vectors and mitigations that shall be sent for publication at the same 
>> time as the protocol specification.
>>
>> Milestones
>>
>> [email-masked] <mailto:[email-masked]>
> routing-discussion mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/routing-discussion
>

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 15 Jan 2018 16:44:44 -0800

Hi,

I find Adrian’s changes perfect and support the charter as per below.

Due to changes in my working situation I didn’t quite participate in initial discussion, starting now.

I have got some ideas of using THRIFT/gRPC alike encoding schema’s for more, than RIFT currently defines, for later thought.

Cheers,

Jeff

From: Rift <[email-masked]> on behalf of Adrian Farrel <[email-masked]>
Reply-To: <[email-masked]>
Date: Monday, January 15, 2018 at 15:07
To: <[email-masked]>
Subject: Re: [Rift] kicking off the charter discussion

Hi,

OLD

NEW

END

Cheers,

Adrian

FYI..

Thanks!

Alvaro.

================

 

Milestones

============

Thanks,

Alia

_______________________________________________ Rift mailing list [email-masked] https://www.ietf.org/mailman/listinfo/rift

---

From: Robert Wilton <[email-masked]>
Date: Tue, 16 Jan 2018 10:04:24 +0000

I was actually wondering whether it wouldn't be better for RIFT to use 
CBOR encoding rather than Thrift or protobuf (that the draft suggests as 
a possible alternative).

Are there reasons why Thrift is a better choice that CBOR (given that 
CBOR is IETF specified)?

Thanks,
Rob

On 16/01/2018 00:44, Jeff Tantsura wrote:
> I have got some ideas of using THRIFT/gRPC alike encoding schema’s for 
> more, than RIFT currently defines, for later thought.
>
> Cheers,
>
> Jeff
>
> *From: *Rift <[email-masked]> on behalf of Adrian Farrel 
> <[email-masked]>
> *Reply-To: *<[email-masked]>
> *Date: *Monday, January 15, 2018 at 15:07
> *To: *<[email-masked]>
> *Subject: *Re: [Rift] kicking off the charter discussion
>
> Hi,
>
> I joined this list a little late to have a neat head of thread to 
> respond to, but here's a response to Alvaro's copy to routing-discussion.
>
> The charter text looks water-tight to me and I'd like to see this WG 
> formed so that the whole community can work on RIFT.
>
> *From:*rtgwg [mailto:[email-masked]] *On Behalf Of *Alvaro Retana
> *Sent:* 06 January 2018 03:25
> *To:* [email-masked]; [email-masked]
> *Subject:* Fwd: [Rift] kicking off the charter discussion
>
> FYI..
>
>     Tony, Jeffrey Zhang, I, and others have been discussing possible
>     RIFT WG charters with Alvaro.  Here is what we have so far. 
>     Comments and improvements would be most welcome.
>
>     ================
>
>     routing in Clos and Fat-Tree networks via a mixture of both
>     link-state and distance-vector techniques colloquially described
>     as 'link-state towards the spine and distance vector towards the
>     leafs'.  RIFT uses this hybrid approach to focus on networks with
>     regular topologies with a high degree of connectivity, a defined
>     directionality, and large scale.
>
>     The RIFT Working Group will work on a standards track
>     specification of a specialized, dynamic routing protocol for Clos
>     and fat-tree network topologies. The protocol will:
>
>     - and provide mechanisms to synchronize a limited key-value
>     data-store that can be used after protocol convergence.
>
>     It is important that nodes participating in the protocol should
>     need only very light configuration and should be able to join a
>     network as leaf nodes simply by connecting to the network using
>     default configuration.
>
>       - an Operational Considerations section to explain how the
>     protocol is configured, deployed, and diagnosed
>       - Security and Privacy Considerations, although this material
>     may refer to a separate Threat Analysis document (q.v.).
>     vectors and mitigations that shall be sent for publication at the
>     same time as the protocol specification.
>
>     Milestones
>
> _______________________________________________ Rift mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/rift
>
>
>

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 16 Jan 2018 09:09:00 -0800

Robert, the newest draft version says that protobuf is a fine alternative
to work with (but discussion thrift/protobuf is very comparable IMO @
capabilities/conceptual span level and _someone_ would have to do the work
to be more than a boilerplate ;-).  And AFAIR CBOR is basically message
pack which  would suffer from the JSON problem of having no type checking
or schema definition which makes it a fine proposition if you just "writing
some internal code where the code is the schema" but how would you
standardize interoperable, backwards compatible formats/protocols that way
and ensure minor/major versioning and so on?

Having said that, serialization is now a huge fertile ground with all kind
of ideas and endless packages roaming the field so the discussion would
really have to be "what are the properties of a serialization approach that
is useful to support solutions to the problem of type X". Having suffered
decades from subtle encoding problems on routing protocols in terms of bugs
and inter-operability issues I would not be particularly leaning towards
adopting anything that doesn't have strong schema and type checking for
that purpose. Of course the hand-written ser/de-sers in routing protocols
had a purpose beyond keeping programmers employed ;-), the packages were
not available and even if they were the available cycles and memory
footprints would not have had supported them until recently ...

And then of course there's proof in the pudding of defining schema,
compiling it, making it run, seeing what really holds up @ scale ... And if
you have something real for RIFT I'm always interested in having a more
detailed discussion, voice some more qualified opinions ;-)

thanks

---- tony

On Tue, Jan 16, 2018 at 2:04 AM, Robert Wilton <[email-masked]> wrote:

> CBOR encoding rather than Thrift or protobuf (that the draft suggests as a
> possible alternative).
>
> Are there reasons why Thrift is a better choice that CBOR (given that CBOR
> is IETF specified)?
> Thanks,
> Rob
>
>
>
> *From: *Rift <[email-masked]> <[email-masked]> on behalf of
> Adrian Farrel <[email-masked]> <[email-masked]>
> *Reply-To: *<[email-masked]> <[email-masked]>
> *To: *<[email-masked]> <[email-masked]>
> I joined this list a little late to have a neat head of thread to respond
> to, but here's a response to Alvaro's copy to routing-discussion.
>
>
>
>   - Security and Privacy Considerations, although this material may refer
> to a separate Threat Analysis document (q.v.).
>
>   - An Applicability Statement that describes how to deploy and configure
> the protocol in networks with different topologies
>
>   - A Security Threat Analysis document that describes the attack vectors
> and mitigations that shall be sent for publication at the same time as the
> protocol specification.
>
> NEW
>
>   - An Applicability Statement that describes how to deploy and configure
> the protocol in networks with different topologies
>
>   - A Security Threat Analysis document that describes the attack vectors
> and mitigations that shall be sent for publication at the same time as the
> protocol specification.
>
> END
>
>
>
> Cheers,
>
> Adrian
>
>
>
>
>
> *From:* rtgwg [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Alvaro Retana
> feedback on the [email-masked] list.
>
>
>
> Thanks!
>
>
>
> Alvaro.
>
>
>
> Tony, Jeffrey Zhang, I, and others have been discussing possible RIFT WG
> charters with Alvaro.  Here is what we have so far.  Comments and
> networks as a result of a trend towards centralized data center network
> architectures that may deliver computation and storage services.
>
> The Routing in Fat Trees (RIFT) protocol addresses the demands of routing
> in Clos and Fat-Tree networks via a mixture of both link-state and
> distance-vector techniques colloquially described as 'link-state towards
> the spine and distance vector towards the leafs'.  RIFT uses this hybrid
> approach to focus on networks with regular topologies with a high degree of
> connectivity, a defined directionality, and large scale.
>
> The RIFT Working Group will work on a standards track specification of a
> specialized, dynamic routing protocol for Clos and fat-tree network
> - support automatic disaggregation of prefixes on link and node failures
> to prevent black-holing and suboptimal routing,
> It is important that nodes participating in the protocol should need only
> very light configuration and should be able to join a network as leaf nodes
> simply by connecting to the network using default configuration.
>
>   - Security and Privacy Considerations, although this material may refer
> to a separate Threat Analysis document (q.v.).
>   - An Applicability Statement that describes how to deploy and configure
> the protocol in networks with different topologies
>   - A Security Threat Analysis document that describes the attack vectors
> and mitigations that shall be sent for publication at the same time as the
> protocol specification.
>
> Milestones
>
> Rift mailing [email-masked]://www.ietf.org/mailman/listinfo/rift
>
>
>

---

From: Tony Li <[email-masked]>
Date: Tue, 16 Jan 2018 09:16:17 -0800

> On Jan 16, 2018, at 9:09 AM, Tony Przygienda <[email-masked]> wrote:
> 
> And then of course there's proof in the pudding of defining schema, compiling it, making it run, seeing what really holds up @ scale ... And if you have something real for RIFT I'm always interested in having a more detailed discussion, voice some more qualified opinions ;-) 

Luddite here.  

Do we have any worked examples of anyone using one of these packages long term in a standard and demonstrating ongoing interoperability? It would seem to me that unless folks are willing to mandate the schema file and the version of the translator to use the odds of actual cross-implementation cross-version interoperability are slim to none.

Consider this one vote for traditional TLVs.

Tony

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 16 Jan 2018 09:38:16 -0800

Tony, unfortunately you are asking here for someone 2 years out of school
with 20 years job experience ;-)  Those packages are too recent, first
"something" that was consumption ready is really just 2008-10 (Thrift) and
the CPU juice & languages are here since only about 4 years to do that kind
of stuff @ scale/speed we need in protocols IME ... Service deployment
folks have tons of experience with service migration and experience there
has been quite good as far I talk to them. And within the big shops service
inter-operability, inter-dependency, forward rolling is keeping busy a lot
of people from what I saw. But yes, they are not "routing protocols" per se
which is a mildly specialized problem we all made careers of ;-)  ...

As to mandate: just like "TLVs" are part of the standard so can a schema be
(and YANGs are standard, aren't they, albeit serving different corner
obviously) and I would argue syntactically a much "cleaner, maintainable,
easier to advance" one when it comes to syntactic correctness of what can
leave the box. [Footnote: semantically, no matter how beautifully you
encode, if you make a mess of inter-dependent, badly described flags with
partitions across multiple instances of things and fail to describe all
boundary/error conditions that can happen, anything can be bad. The limit
here is the capability of the protocol designers to create orthogonal,
clean algebras or object/relationship model] ... And the
"each-their-own-TLV-parser-interoperability" is based on the tactic
understanding that no'one tries to break the other guys' parser too hard
with crazy stuff being sent, unless of course a bug happens and "who could
have known" and "oh, will never happen again". And to fix things in specs
after the fact is not fun and sometimes not even possible. Having done
RFC7606 this does not make for maintainable code that inspires a lot of
confidence ...  And frankly, while you were gone quite a discussion was
raging whether RFC7606 is a bug or a feature, IMO it's both since it
expresses "well meaning intentions" which sometimes can just make this
paved road so much more slippery ...

I fully acknowledge that TLVs saved the Internet's bacon for years to come
and there was no practical alternative for those years but routing
protocols aren't a "dead language" yet and we allegedly made a bit of a
pig's ear of using the technologies in HW and SW given to us over last
decade+ or so [except IDR, this one is willing to burn any memory/CPU you
give it before it's soldered on] ;-)

Ultimately, schemas are just "serialization" and very, very useful stuff we
put into TLVs like "transitive" and "optional" properties can only be
partially encoded that way and may be added (think  optional being
"optional" in thrift and mandatory being more of "required" but something
like "transitory" cannot be expressed in those schemas since it really is
specific for "diffused computation"). So TLVs lessons-learned will be moved
forward and surely not forgotten ...

Further continuation of this is rather a bar BoF than mailing list fodder
IMO ...

thanks

--- tony

On Tue, Jan 16, 2018 at 9:16 AM, Tony Li <[email-masked]> wrote:

> Do we have any worked examples of anyone using one of these packages long
> term in a standard and demonstrating ongoing interoperability? It would
> seem to me that unless folks are willing to mandate the schema file and the
> version of the translator to use the odds of actual cross-implementation
> cross-version interoperability are slim to none.
>

---

From: Robert Wilton <[email-masked]>
Date: Tue, 16 Jan 2018 17:56:23 +0000

Hi Tony,

I don't know of the relative benefits of protobuf vs thrift, but I was 
more thinking of the "eat your own dog food", and I thought that one of 
the aims for CBOR was to act as a robust encoding for protocol messages, 
i.e. to replace the buggy TLV parsing.

When I looked at CBOR it seemed to compare favorably (size and 
performance wise) to other binary serialization protocols.  I.e. if a 
new IETF protocol is going to use a binary serialization protocol other 
than the IETF specified one then at least it should warrant some proper 
discussion. ;-)

Regarding specifying the format/schema definition (and validation of 
messages), there is a CBOR WG draft for that: 
https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl

Thanks,
Rob

On 16/01/2018 17:09, Tony Przygienda wrote:
> Robert, the newest draft version says that protobuf is a fine 
> alternative to work with (but discussion thrift/protobuf is very 
> comparable IMO @ capabilities/conceptual span level and _someone_ 
> would have to do the work to be more than a boilerplate ;-).  And 
> AFAIR CBOR is basically message pack which  would suffer from the JSON 
> problem of having no type checking or schema definition which makes it 
> a fine proposition if you just "writing some internal code where the 
> code is the schema" but how would you standardize interoperable, 
> backwards compatible formats/protocols that way and ensure minor/major 
> versioning and so on?
>
> Having said that, serialization is now a huge fertile ground with all 
> kind of ideas and endless packages roaming the field so the discussion 
> would really have to be "what are the properties of a serialization 
> approach that is useful to support solutions to the problem of type 
> X". Having suffered decades from subtle encoding problems on routing 
> protocols in terms of bugs and inter-operability issues I would not be 
> particularly leaning towards adopting anything that doesn't have 
> strong schema and type checking for that purpose. Of course the 
> hand-written ser/de-sers in routing protocols had a purpose beyond 
> keeping programmers employed ;-), the packages were not available and 
> even if they were the available cycles and memory footprints would not 
> have had supported them until recently ...
>
> compiling it, making it run, seeing what really holds up @ scale ... 
> And if you have something real for RIFT I'm always interested in 
> having a more detailed discussion, voice some more qualified opinions ;-)
>
> thanks
>
> ---- tony
>
>
>
> On Tue, Jan 16, 2018 at 2:04 AM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I was actually wondering whether it wouldn't be better for RIFT to
>     use CBOR encoding rather than Thrift or protobuf (that the draft
>     suggests as a possible alternative).
>
>     Are there reasons why Thrift is a better choice that CBOR (given
>     that CBOR is IETF specified)?
>
>     Thanks,
>     Rob
>
>
>
>>     I have got some ideas of using THRIFT/gRPC alike encoding
>>     schema’s for more, than RIFT currently defines, for later thought.
>>
>>     Cheers,
>>
>>     Jeff
>>
>>     *From: *Rift <[email-masked]>
>>     <mailto:[email-masked]> on behalf of Adrian Farrel
>>     <[email-masked]> <mailto:[email-masked]>
>>     *Reply-To: *<[email-masked]> <mailto:[email-masked]>
>>     *To: *<[email-masked]> <mailto:[email-masked]>
>>     The charter text looks water-tight to me and I'd like to see this
>>     WG formed so that the whole community can work on RIFT.
>>
>>     *To:* [email-masked]
>>     <mailto:[email-masked]>; [email-masked]
>>     <mailto:[email-masked]>
>>     If you are interested in this topic, please make comments and
>>     send feedback on the [email-masked] <mailto:[email-masked]> list.
>>
>>     Thanks!
>>
>>     Alvaro.
>>
>>         Tony, Jeffrey Zhang, I, and others have been discussing
>>         possible RIFT WG charters with Alvaro.  Here is what we have
>>         so far.  Comments and improvements would be most welcome.
>>
>>         ================
>>
>>         Clos and Fat-Tree topologies have gained prominence in data
>>         center networks as a result of a trend towards centralized
>>         data center network architectures that may deliver
>>         computation and storage services.
>>
>>         The Routing in Fat Trees (RIFT) protocol addresses the
>>         demands of routing in Clos and Fat-Tree networks via a
>>         mixture of both link-state and distance-vector techniques
>>         colloquially described as 'link-state towards the spine and
>>         distance vector towards the leafs'.  RIFT uses this hybrid
>>         approach to focus on networks with regular topologies with a
>>         high degree of connectivity, a defined directionality, and
>>         large scale.
>>
>>         specification of a specialized, dynamic routing protocol for
>>         Clos and fat-tree network topologies. The protocol will:
>>
>>         - support automatic disaggregation of prefixes on link and
>>         node failures to prevent black-holing and suboptimal routing,
>>         It is important that nodes participating in the protocol
>>         should need only very light configuration and should be able
>>         to join a network as leaf nodes simply by connecting to the
>>         network using default configuration.
>>
>>         - A Standards Track specification based on
>>         draft-przygienda-rift. The document will include:
>>
>>           - Security and Privacy Considerations, although this
>>         material may refer to a separate Threat Analysis document (q.v.).
>>           - An Applicability Statement that describes how to deploy
>>         and configure the protocol in networks with different topologies
>>           - A Security Threat Analysis document that describes the
>>         attack vectors and mitigations that shall be sent for
>>         publication at the same time as the protocol specification.
>>
>>         Milestones
>>
>>         <https://www.ietf.org/mailman/listinfo/rift>
>>
>>     <https://www.ietf.org/mailman/listinfo/rift>
>>
>>
>>
>>     <https://www.ietf.org/mailman/listinfo/rift>
>
>
>     <https://www.ietf.org/mailman/listinfo/rift>
>
>

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 16 Jan 2018 10:58:02 -0800

Robert, sure, thanks for the pointers, it looks interesting, let's see how
it progresses and whether they produce a standard/implementation given it's
right now a draft couple months old ... If someone has the drive and will
do work on it I personally think that it's a viable discussion point
whether something like this should be part of RIFT charter ...

--- tony

On Tue, Jan 16, 2018 at 9:56 AM, Robert Wilton <[email-masked]> wrote:

> more thinking of the "eat your own dog food", and I thought that one of the
> aims for CBOR was to act as a robust encoding for protocol messages, i.e.
> to replace the buggy TLV parsing.
>
> When I looked at CBOR it seemed to compare favorably (size and performance
> wise) to other binary serialization protocols.  I.e. if a new IETF protocol
> is going to use a binary serialization protocol other than the IETF
> specified one then at least it should warrant some proper discussion. ;-)
>
>> *From: *Rift <[email-masked]> <[email-masked]> on behalf
>> of Adrian Farrel <[email-masked]> <[email-masked]>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 16 Jan 2018 14:44:56 -0500

Tony,

Thrift is used all over Apache and there are large ecosystems built on it.
I had experience with protobuf when I worked at Google; that was over 10
years ago and while there
has been evolution, it hasn't been radical.  Again, there are large systems
using this.

Personally, I'd prefer to avoid the not-invented-here problems; there's a
large amount of really
excellent and solid open-source work.  Specific technical concerns are, of
course, important but also
part of the meat of the planned WG.  IMHO, it'd be a shame to believe that
there are no better ways to
do serialization/de-serialization than what the IETF did over 25 years ago.

Regards,
Alia

---

From: Tony Li <[email-masked]>
Date: Tue, 16 Jan 2018 12:30:36 -0800

Alia,

> I had experience with protobuf when I worked at Google; that was over 10 years ago and while there
> has been evolution, it hasn't been radical.  Again, there are large systems using this.
> 
> Personally, I'd prefer to avoid the not-invented-here problems; there's a large amount of really
> excellent and solid open-source work.  Specific technical concerns are, of course, important but also
> part of the meat of the planned WG.  IMHO, it'd be a shame to believe that there are no better ways to

Thank you.  Perhaps I should also point out that I’ve used protobufs in a product or three already. I do understand the capabilities and benefits and I like them. However, there are limitations and I hope that folks recognize them before we go mandating things.

The IETF has had a long tradition of mandating the protocol but not the implementation. This is moving the line. Big time.

Please think very hard before doing this.

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 16 Jan 2018 12:34:31 -0800

Alia,

Tony

---

From: Alia Atlas <[email-masked]>
Date: Tue, 16 Jan 2018 15:44:57 -0500

Tony,

On Tue, Jan 16, 2018 at 3:30 PM, Tony Li <[email-masked]> wrote:

> Thank you.  Perhaps I should also point out that I’ve used protobufs in a
> product or three already. I do understand the capabilities and benefits and
> I like them. However, there are limitations and I hope that folks recognize
> them before we go mandating things.
>

Absolutely!  I'm not surprised that you have familiarity with them - and
discussing the benefits and limitations would be very useful.

> The IETF has had a long tradition of mandating the protocol but not the
> implementation. This is moving the line. Big time.
>

I think the intent would be to reference a suitable document for Thrift or
protobufs - not to mandate a particular implementation be used.
Separately from the RIFT work, but addressing this type of issue,  I
co-authored draft-atlas-external-normref-00 which is trying to clarify
and describe under what circumstances a reference to an external
specification is acceptable and how to handle that.

Many of us are familiar with the problems of a pervasive single
implementation - with the associated bugs and fragility.
My personal hope is re-use and improvement, so that we can describe in data
models and get out of a requirement for hand-written
special-cased code.

Regards,
Alia

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 16 Jan 2018 12:45:08 -0800

> implementation. This is moving the line. Big time.

Here I'm somehow missing the point utterly. How is providing a schema
mandating the implementation? Is Yang mandating implementations and we
should stop it today? And providing TLV is also "mandating implementation"
and saying I would argue "it has to  run on TCP" even more so ... no'one
says anywhere "you must use compiler X or language Y or processor Z or
anything like that". We just use _a practical_ schema language to get off
the cycle of hand-knit parsers and non-orthogonal encodings everywhere to
increase the maintainability and delivery cycles of code.

NIY is another topic and orthogonal ...

--- tony

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 16 Jan 2018 12:47:11 -0800

> NIY is another topic and orthogonal ...
Sorry, NIH of course (as in IBM and DEC times where only
hand-brewed-at-home was worthy enough) ...

--- tony

---

From: Tony Li <[email-masked]>
Date: Tue, 16 Jan 2018 12:59:10 -0800

> Here I'm somehow missing the point utterly. How is providing a schema mandating the implementation? Is Yang mandating implementations and we should stop it today? And providing TLV is also "mandating implementation" and saying I would argue "it has to  run on TCP" even more so ... no'one says anywhere "you must use compiler X or language Y or processor Z or anything like that". We just use _a practical_ schema language to get off the cycle of hand-knit parsers and non-orthogonal encodings everywhere to increase the maintainability and delivery cycles of code. 

If we select Thrift/protobuf/CDDL and publish a schema, then we are putting a stake in the ground. From that point, implementors are pretty restricted. Just how many processors do you expect to exist given a particular DDL and target language? The pragmatic answer is one. Further more, there will be N versions of that one, each with its own quirks and not necessarily backward compatible.

Tony