Adding upstream version 9.1.upstream/9.1

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

4 files changed, 102 insertions, 0 deletions

diff --git a/doc/accords/README.md b/doc/accords/README.md
new file mode 100644
index 0000000..0461b04
--- /dev/null
+++ b/doc/accords/README.md
@@ -0,0 +1,32 @@
+FRR accords
+===========
+
+
+This directory contains some text documents with "accords" agreed upon by the
+FRR community.  The idea here is that by passing text documents through the
+PR/review process, consensus for work items, design decisions, etc. can be
+established and documented.  They can also be changed later by followup PRs if
+consensus shifts.  This is intended to reduce friction, and provide more
+transparency for newcomers & less frequent contributors.
+
+Examples of things that could go here:
+
+- agreement on how to fix some deeper-seated existing shortcoming in FRR that
+  might take some time to fix, to get consensus before putting time into it.
+
+- larger design (especially system/package integration) decisions that are not
+  immediately tangible to the code.
+
+- scoping decisions, particularly negative (i.e. we decided at some point that
+  FRR is not the right place for something) - these are otherwise lost in some
+  ancient closed PR, and some new contributor might be unaware and waste time.
+
+Files in this directory are not formatted in any specific way and not rendered
+into documentation.  They're intended to be read with your code editor of
+choice.
+
+To avoid misunderstandings, there is one "rule" about wording:  the consensus
+actual is worded with "will", "going to", "is" - this reflects the idea that
+when the PR is merged, it *is* community consensus.  Words like "should",
+"would" or "might" should be limited to context and reference that is provided
+as rationale for the consensus.
diff --git a/doc/accords/cli-colors b/doc/accords/cli-colors
new file mode 100644
index 0000000..04bdfc7
--- /dev/null
+++ b/doc/accords/cli-colors
@@ -0,0 +1,44 @@
+Adding colors to FRR CLI output
+===============================
+
+
+There were multiple approaches/attempts to get colored output for the CLI into
+FRR, most recently End of 2022 in PR #12497.  After some discussion, some items
+crystallized out:
+
+First, generally speaking, colors (or other rich output formatting) must be
+used sparingly.  In particular, e.g. "every IP address" is not something to
+color.  The output formatting needs to have an actual purpose to improve UX,
+not turn it into a christmas tree.
+
+In the long run, the CLI will hopefully become a YANG frontend.  In that case,
+the CLI frontend component is a great place to apply all kinds of output/UI/UX
+features.  However, this is a long way off.
+
+That said, an implementation in the current vtysh+daemon ecosystem is not out
+of the question, especially if the use of colors/formatting is limited to
+important places (which is desirable anyway - see general statement above.)
+We don't want to litter formatting all over every single vty_out call.
+
+A color option on a per-command/DEFUN level (i.e. the way `[json]` is done) was
+rejected.  The decision to color output must take information from vtysh's
+environment into account, notably the TERM environment variable, the NO_COLOR
+environment variable, and whether stdout is a terminal or not.  An explicit
+`--color` switch (or `terminal color` vtysh command, or other similar things)
+is needed too.  To be clear, the switch must not be on individual commands, it
+needs to be on the vtysh session level.
+
+Lastly, the output pager needs to work with this.
+
+
+Suggested implementation
+------------------------
+
+(not part of the consensus / accord, only to record discussion)
+
+As far as discussion went, the most promising approach to actually implement
+this is to put some type of unconditional formatting tag into daemon's vty_out
+calls.  This would be some escape-like sequence - an actual ANSI color code
+itself is not particularly readable or pretty, though that would work as well.
+vtysh would then, while passing through the output from the daemons, replace or
+remove these tags according to terminal/user settings.
diff --git a/doc/accords/frr-service-is-watchfrr b/doc/accords/frr-service-is-watchfrr
new file mode 100644
index 0000000..2301c83
--- /dev/null
+++ b/doc/accords/frr-service-is-watchfrr
@@ -0,0 +1,16 @@
+The "FRR" service unit is watchfrr
+==================================
+
+
+"FRR" on the distribution/OS level is one service (generally called "frr").
+Exposing individual daemons (zebra, staticd, bgpd, ...) as service units does
+not match FRR's internal expectations.
+
+At some future point, watchfrr will add functionality to receive "router bgp",
+"router ospf" etc. commands (or their YANG variants) and automatically start
+the required daemons.  In particular with multi-instance setups, this will
+simplify config (no more mucking around /etc/frr/daemons - if watchfrr
+understands which daemons are needed by a given config, the daemons file is
+pointless.)
+
+This to some degree assumes an "integrated-config world".
diff --git a/doc/accords/integrated-config-wins b/doc/accords/integrated-config-wins
new file mode 100644
index 0000000..5a02b99
--- /dev/null
+++ b/doc/accords/integrated-config-wins
@@ -0,0 +1,10 @@
+Integrated config wins
+======================
+
+
+The use of split-configuration setups (zebra.conf, staticd.conf, bgpd.conf,
+etc.) in FRR is considered deprecated and will go away at some point.
+
+At this point there is no timeline yet on removing split-config support, and
+this needs to go through an extensive deprecation period with increasingly
+loud user warnings.