Decode BGP Shutdown Communication messages (RFC 8203)

[Job Snijders]

Hi Ondrej,

Thank you for your work on this patch. When sending in my code i
realised it was a bit rough on the edges, and secretly hoped that a more
experienced BIRD developer would take pity and polish it up.
Appreciated!

On Tue, Sep 26, 2017 at 02:22:20PM +0200, Ondrej Zajicek wrote:
> On Tue, Sep 26, 2017 at 10:14:11AM +0200, Peter Hessler wrote:
> > On 2017 Sep 19 (Tue) at 20:53:47 +0200 (+0200), Ondrej Zajicek wrote:
> > :Merged with some significant changes, with support for both RX and
> > TX of :shutdown communication:
> > :
> > :Unfortunately, that means that from Unix shell you have to do
> > double qouting:
> > :
> > :birdc disable bgp1 '"hi, we will upgrade to bird 1.6.4"'
> > :
> > 
> > Um, requiring double quoting violates POLA.  This isn't user
> > friendly at all.
> 
> Well, while i consider it cumbersome, i would argue that it is
> consistent with POLA. Anyone who take into account two premises,
> namely:
> 
> 1) BIRD always requires quotes for string constants
> 2) Quoting is removed by shell

I beg to differ... this is not what UNIX-style users expect from
programs. I'd expect:

    $ sudo birdc disable bgp1 "hi, we will upgrade to bird 1.6.4"

or maybe 

    $ sudo birdc disable bgp1 message "hi, we will upgrade to bird 1.6.4"

to work like that. 

Another aspect, from the
    
    $ sudo birdc show protocols all bgp1

output it is not entirely clear whether the Message is the last message
that has been _sent_ to the EBGP neighbor, or is the last message that
has been _received_ from that neighbor. Might be good to clarify that a
bit (perhaps add RX or TX as prefix?).

> > It shouldn't be that hard to only require one set of quotes in both
> > the unix shell and the birdc shell.
> 
> We use the same lexer and parser for both CLI and arguments and quotes
> are not just for token separation (which is already done by shell for
> arguments), but are intrinsic part of string tokens to distinquish
> them from symbol tokens. Changing that would require significant
> changes to lexer with likely impact on backward compatibility.

I see, that is unfortunate.

Another challenge may be that the proposed patch doesn't offer feature
parity in terms of the bird.conf approach. I'm aware of many deployments
that never use "birdc enable|disable" from the command line, but just
"generate && rsync && birdc configure" to push out configs. This way the
running configuration and the startup configuration are always in sync,
which often is a desirable property.

Kind regards,

Job