GoBGP: BGP Implemented in Go • Hacker News Board

Re: GoBGP: BGP Implemented in Go

#121

Post by signa11 » Tue, Apr 19, 2016, 4:40 AM UTC

tptacek wrote: post #105

pests wrote: post #82

Earlier quoted context omitted.

What is the cool trick to implementing BER?

you encode it back-to-front i don't even care anymore.

> you encode it back-to-front

sorry, but i still don't grok it. for example, if you take a person 'object' defined as :

Person {

     name string (or equivalent asn.1 type-name, with type-identifier == 1)

     age  int (or equivalent asn.1 type-name, with type-identifier == 2)

}

since b.e.r is basically a tlv (type-length-value) encoding, a person with name "james" with age '10' i.e.

james_person = Person(name = 'james', age = 10)

gets hex-encoded as :

"james" : 01 05 6a 61 6d 65 73

"10" : 02 01 0A

so the whole thing looks like this:

"01 05 6a 61 6d 65 73 02 0A".

ofcourse this would be prepended with appropriate type-number for 'Person' with corresponding length.

if we assume that 'Person' gets a type-identifier == 3, then 'james_person' instance would be encoded as:

"03 06 01 05 6a 61 6d 65 73 02 0A"

where '06' == total length (6 bytes) of this instance of person object.

may you please elucidate your trick with the above example ? thanks for your insights !

Re: GoBGP: BGP Implemented in Go

#122

Post by solidsnack9000 » Tue, Apr 19, 2016, 4:46 AM UTC

dsr_ wrote: post #40

tptacek wrote: post #29

Earlier quoted context omitted.

No. I've written SNMP from scratch in Ruby, Python, and C++. DER ASN.1 for X.509 might be treacherous (simply in the sense that any mistake you make at all will be ruinous), but that's just not the case for SNMP's BER. The whole point of using Rust or Go instead of C is that the "peril" of implementing things like ASN.1/BER is pretty much eliminated. As for your former point: I don't follow. Go's deployment infrastru…

The viewpoint you were espousing was, if I understand correctly: I should replace all my existing services with Go/Rust equivalents, unless they handle packets directly. My objection is that you are advocating this in the same narrow-focused way that people advocate node with npm, python with pip, ruby with gem: little or no cooperation with the whole system is available yet. This is perfectly fine from the point of…

Actually, Rust would support updates for your SSL, ASN.1 and other libraries; because native bindings are widely accepted and used with Rust.

Re: GoBGP: BGP Implemented in Go

#123

Post by solidsnack9000 » Tue, Apr 19, 2016, 4:47 AM UTC

tptacek wrote: post #29

dsr_ wrote: post #23

Earlier quoted context omitted.

...well, because of the primary shortcoming of the Go system: lack of standard infrastructure to manage the inevitable updates. Let's say I have replaced bind, unbound, ntpd, postfix, openssh, dovecot, snmpd and asterisk with Go-written equivalents. Three weeks later, there is a bug found in the standard Go TLS library. My distro ships all the packages noted above, but not their Go-equivalents, so my work load now in…

No. I've written SNMP from scratch in Ruby, Python, and C++. DER ASN.1 for X.509 might be treacherous (simply in the sense that any mistake you make at all will be ruinous), but that's just not the case for SNMP's BER. The whole point of using Rust or Go instead of C is that the "peril" of implementing things like ASN.1/BER is pretty much eliminated. As for your former point: I don't follow. Go's deployment infrastru…

> Go's deployment infrastructure is a superset of C's...

That is true; but updates to native libs that would propagate to C, Python &al. will generally not propagate to Go because, like Java, Go eschews native bindings.

Re: GoBGP: BGP Implemented in Go

#124

Post by lightcatcher » Tue, Apr 19, 2016, 5:15 AM UTC

signa11 wrote: post #119

tptacek wrote: post #11

This is the sort of thing Go really shines on: network and infrastructure services that would ordinarily be provided by big ugly C programs, where the latency requirements are significant but not as bad as raw packet forwarding. If your current best alternative is a C program, I'm not sure why you wouldn't seriously consider replacing any of the following with Go (or Rust) programs: * Authority DNS * DNS caches * ntp…

> I'm not sure why you wouldn't seriously consider replacing any of the following with Go just curious about this: are there folks trying out dpdk with go ? implementing these control-plane applications in vanilla sockets (or close-to-zero-wrappers on those), doesn't seem fruitful anymore. fwiw, i have been doing dpdk stuff, but have been mostly using C...

Seconded on the dpdk point. I've been working with kernel bypass networking in C but it seems to me that the asynchronous queue based APIs would be perfect for Golang or even Javascript. The only project I've seen so far to make kernel bypass networking nicer to program is http://www.seastar-project.org/ (which has DPDK support)

Re: GoBGP: BGP Implemented in Go

#125

Post by vbernat » Tue, Apr 19, 2016, 7:23 AM UTC

pjmlp wrote: post #76

vbernat wrote: post #68

Earlier quoted context omitted.

gcc has no problem with static linking. glibc can be statically linked (with gcc or clang) except the pluggable parts, which is NSS. How would you reconcile static linking and plugins?

By making use of plugin selection at compile time, like we used to do when dynamic linking wasn't available in mainstream OSes.

The whole idea of NSS is to be pluggable to let the local administrator chooses what they need.

Re: GoBGP: BGP Implemented in Go

#126

Post by pjmlp » Tue, Apr 19, 2016, 7:45 AM UTC

vbernat wrote: post #125

pjmlp wrote: post #76

Earlier quoted context omitted.

By making use of plugin selection at compile time, like we used to do when dynamic linking wasn't available in mainstream OSes.

The whole idea of NSS is to be pluggable to let the local administrator chooses what they need.

Back in the day when UNIX only had static linking that type of plugability was achieved via configuration files and UNIX IPC.

Dynamic linking just makes it easy to program for the same scenario.

Re: GoBGP: BGP Implemented in Go

#127

Post by technion » Tue, Apr 19, 2016, 10:08 AM UTC

arca_vorago wrote: post #89

Would elixir or erlang also be a good potential language for bgp/quagga/zebra?

I feel "BGP in Erlang" would be exactly the kind of thing I could implement well - even if it did feel icky having to implement "MD5 Authentication" in 2016.

The problem with those sorts of projects however, is inertia. The average hobbyist rarely ever uses BGP. Large networks and ISPs aren't going to implement my personal project as a critical component to keeping their entire infrastructure online without a very good reason.

This project looks promising, I'm hoping it doesn't suffer this problem.

Re: GoBGP: BGP Implemented in Go

#128

Post by saturn_vk » Tue, Apr 19, 2016, 10:25 AM UTC

dsr_ wrote: post #40

tptacek wrote: post #29

Earlier quoted context omitted.

No. I've written SNMP from scratch in Ruby, Python, and C++. DER ASN.1 for X.509 might be treacherous (simply in the sense that any mistake you make at all will be ruinous), but that's just not the case for SNMP's BER. The whole point of using Rust or Go instead of C is that the "peril" of implementing things like ASN.1/BER is pretty much eliminated. As for your former point: I don't follow. Go's deployment infrastru…

The viewpoint you were espousing was, if I understand correctly: I should replace all my existing services with Go/Rust equivalents, unless they handle packets directly. My objection is that you are advocating this in the same narrow-focused way that people advocate node with npm, python with pip, ruby with gem: little or no cooperation with the whole system is available yet. This is perfectly fine from the point of…

You can always use gccgo, which supports dynamic linking of the go stdlib

Re: GoBGP: BGP Implemented in Go

#129

Post by _0w8t » Tue, Apr 19, 2016, 11:35 AM UTC

vbernat wrote: post #125

pjmlp wrote: post #76

Earlier quoted context omitted.

By making use of plugin selection at compile time, like we used to do when dynamic linking wasn't available in mainstream OSes.

The whole idea of NSS is to be pluggable to let the local administrator chooses what they need.

As a result of that good intention glibc must now be compiled into each and every program that wants to allow a customization complicating life for anybody who writes system software in anything but C/C++. I would rather preferred for NSS to never happen and instead Linux defined a set of services available over unix sockets for things like DNS resolution or user/group databases.

Re: GoBGP: BGP Implemented in Go

#130

Post by sre_ops » Tue, Apr 19, 2016, 11:58 AM UTC

tptacek wrote: post #109

sre_ops wrote: post #57

Earlier quoted context omitted.

Yes. It currently runs over 70% of global internet and considering all kinds of error conditions that show up on the global internet the code is extremely stable.

Sendmail used to run on something like 90% of the global Internet. And mail in the 1990s pretty much did work, pretty reliably. Would you have banked your site's security on the quality of Sendmail 8.6.12's code?

It is unfortunate that people who downvote comments actually do not have an iota of clue about the topic which the comment about sendmail clearly illustrates.

Bugs in BGP implementation kill internet in real-time. To a point where in certain cases it would be needed to literally power off all the affected routers at the same time globally after isolating the bad actor and disconnecting it.