Merge branch 'master' into mq-filter-stack

2 files changed, 82 insertions, 15 deletions

diff --git a/doc/bird.sgml b/doc/bird.sgml
index 8594b930..e0b60c81 100644
--- a/doc/bird.sgml
+++ b/doc/bird.sgml
@@ -561,7 +561,7 @@ include "tablename.conf";;
 	can be seen (together with other symbols) using 'show symbols' command.
 
 	<tag><label id="opt-attribute">attribute <m/type/ <m/name/</tag>
-	Define a custom route attribute. You can set and get it in filters like
+	Declare a custom route attribute. You can set and get it in filters like
 	any other route atribute. This feature is intended for marking routes
 	in import filters for export filtering purposes instead of locally
 	assigned BGP communities which have to be deleted in export filters.
@@ -1159,7 +1159,7 @@ int var;
 <p>As you can see, a filter has a header, a list of local variables, and a body.
 The header consists of the <cf/filter/ keyword followed by a (unique) name of
 filter. The list of local variables consists of <cf><M>type name</M>;</cf>
-pairs where each pair defines one local variable. The body consists of <cf>
+pairs where each pair declares one local variable. The body consists of <cf>
 { <M>statements</M> }</cf>. Each <m/statement/ is terminated by a <cf/;/. You
 can group several statements to a single compound statement by using braces
 (<cf>{ <M>statements</M> }</cf>) which is useful if you want to make a bigger
@@ -1188,7 +1188,7 @@ called like in C: <cf>name(); with_parameters(5);</cf>. Function may return
 values using the <cf>return <m/[expr]/</cf> command. Returning a value exits
 from current function (this is similar to C).
 
-<p>Filters are declared in a way similar to functions except they can't have
+<p>Filters are defined in a way similar to functions except they can't have
 explicit parameters. They get a route table entry as an implicit parameter, it
 is also passed automatically to any functions called. The filter must terminate
 with either <cf/accept/ or <cf/reject/ statement. If there's a runtime error in
@@ -1571,11 +1571,20 @@ if 1234 = i then printn "."; else {
 <label id="route-attributes">
 
 <p>A filter is implicitly passed a route, and it can access its attributes just
-like it accesses variables. Attempts to access undefined attribute result in a
-runtime error; you can check if an attribute is defined by using the
-<cf>defined( <m>attribute</m> )</cf> operator. One notable exception to this
-rule are attributes of bgppath and *clist types, where undefined value is
-regarded as empty bgppath/*clist for most purposes.
+like it accesses variables. There are common route attributes, protocol-specific
+route attributes and custom route attributes. Most common attributes are
+mandatory (always defined), while remaining are optional.  Attempts to access
+undefined attribute result in a runtime error; you can check if an attribute is
+defined by using the <cf>defined( <m>attribute</m> )</cf> operator. One notable
+exception to this rule are attributes of bgppath and *clist types, where
+undefined value is regarded as empty bgppath/*clist for most purposes.
+
+Attributes can be defined by just setting them in filters. Custom attributes
+have to be first declared by <ref id="opt-attribute" name="attribute"> global
+option. You can also undefine optional attribute back to non-existence by using
+the <cf>unset( <m/attribute/ )</cf> operator.
+
+Common route attributes are:
 
 <descrip>
 	<tag><label id="rta-net"><m/prefix/ net</tag>
@@ -1642,8 +1651,8 @@ regarded as empty bgppath/*clist for most purposes.
 	compare internal distances to boundary routers (see below).
 </descrip>
 
-<p>There also exist protocol-specific attributes which are described in the
-corresponding protocol sections.
+<p>Protocol-specific route attributes are described in the corresponding
+protocol sections.
 
 
 <sect>Other statements
@@ -1653,7 +1662,7 @@ corresponding protocol sections.
 
 <descrip>
 	<tag><label id="assignment"><m/variable/ = <m/expr/</tag>
-	Set variable to a given value.
+	Set variable (or route attribute) to a given value.
 
 	<tag><label id="filter-accept-reject">accept|reject [ <m/expr/ ]</tag>
 	Accept or reject the route, possibly printing <cf><m>expr</m></cf>.
@@ -2186,12 +2195,23 @@ using the following configuration parameters:
 	<cf/local 10.0.0.1; local as 65000;/ are valid). This parameter is
 	mandatory.
 
-	<tag><label id="bgp-neighbor">neighbor [<m/ip/] [port <m/number/] [as <m/number/]</tag>
+	<tag><label id="bgp-neighbor">neighbor [<m/ip/ | range <m/prefix/] [port <m/number/] [as <m/number/] [internal|external]</tag>
 	Define neighboring router this instance will be talking to and what AS
 	it is located in. In case the neighbor is in the same AS as we are, we
-	automatically switch to iBGP. Optionally, the remote port may also be
-	specified. Like <cf/local/ parameter, this parameter may also be used
-	multiple times with different sub-options. This parameter is mandatory.
+	automatically switch to IBGP. Alternatively, it is possible to specify
+	just <cf/internal/ or </cf/external/ instead of AS number, in that case
+	either local AS number, or any external AS number is accepted.
+	Optionally, the remote port may also be specified. Like <cf/local/
+	parameter, this parameter may also be used multiple times with different
+	sub-options. This parameter is mandatory.
+
+	It is possible to specify network prefix (with <cf/range/ keyword)
+	instead of explicit neighbor IP address. This enables dynamic BGP
+	behavior, where the BGP instance listens on BGP port, but new BGP
+	instances are spawned for incoming BGP connections (if source address
+	matches the network prefix). It is possible to mix regular BGP instances
+	with dynamic BGP instances and have multiple dynamic BGP instances with
+	different ranges.
 
 	<tag><label id="bgp-iface">interface <m/string/</tag>
 	Define interface we should use for link-local BGP IPv6 sessions.
@@ -2224,6 +2244,16 @@ using the following configuration parameters:
 	session. Default: the address of the local end of the interface our
 	neighbor is connected to.
 
+	<tag><label id="bgp-dynamic-name">dynamic name "<m/text/"</tag>
+	Define common prefix of names used for new BGP instances spawned when
+	dynamic BGP behavior is active. Actual names also contain numberic
+	index to distinguish individual instances.  Default: "dynbgp".
+
+	<tag><label id="bgp-dynamic-name">dynamic name digits <m/number/</tag>
+	Define minimum number of digits for index in names of spawned dynamic
+	BGP instances. E.g., if set to 2, then the first name would be
+	"dynbgp01". Default: 0.
+
 	<tag><label id="bgp-strict-bind">strict bind <m/switch/</tag>
 	Specify whether BGP listening socket should be bound to a specific local
 	address (the same as the <cf/source address/) and associated interface,
@@ -2565,6 +2595,15 @@ be used in explicit configuration.
 <p>BGP channels have additional config options (together with the common ones):
 
 <descrip>
+	<tag><label id="bgp-mandatory">mandatory <m/switch/</tag>
+	When local and neighbor sets of configured AFI/SAFI pairs differ,
+	capability negotiation ensures that a common subset is used. For
+	mandatory channels their associated AFI/SAFI must be negotiated
+	(i.e., also announced by the neighbor), otherwise BGP session
+	negotiation fails with <it/'Required capability missing'/ error.
+	Regardless, at least one AFI/SAFI must be negotiated in order to BGP
+	session be successfully established. Default: off.
+
 	<tag><label id="bgp-next-hop-keep">next hop keep <m/switch/|ibgp|ebgp</tag>
 	Do not modify the Next Hop attribute and advertise the current one
 	unchanged even in cases where our own local address should be used
@@ -3230,6 +3269,8 @@ protocol ospf [v2|v3] &lt;name&gt; {
 	tick &lt;num&gt;;
 	ecmp &lt;switch&gt; [limit &lt;num&gt;];
 	merge external &lt;switch&gt;;
+	graceful restart &lt;switch&gt;|aware;
+	graceful restart time &lt;num&gt;;
 	area &lt;id&gt; {
 		stub;
 		nssa;
@@ -3373,6 +3414,31 @@ protocol ospf [v2|v3] &lt;name&gt; {
 	from different LSAs are treated as separate even if they represents the
 	same destination. Default value is no.
 
+	<tag><label id="ospf-graceful-restart">graceful restart <m/switch/|aware</tag>
+	When an OSPF instance is restarted, neighbors break adjacencies and
+	recalculate their routing tables, which disrupts packet forwarding even
+	when the forwarding plane of the restarting router remains intact.
+	<rfc id="3623"> specifies a graceful restart mechanism to alleviate this
+	issue. For OSPF graceful restart, restarting router originates
+	Grace-LSAs, announcing intent to do graceful restart. Neighbors
+	receiving these LSAs enter helper mode, in which they ignore breakdown
+	of adjacencies, behave as if nothing is happening and keep old routes.
+	When adjacencies are reestablished, the restarting router flushes
+	Grace-LSAs and graceful restart is ended.
+
+	This option controls the graceful restart mechanism. It has three
+	states: Disabled, when no support is provided. Aware, when graceful
+	restart helper mode is supported, but no local graceful restart is
+	allowed (i.e. helper-only role). Enabled, when the full graceful restart
+	support is provided (i.e. both restarting and helper role). Note that
+	proper support for local graceful restart requires also configuration of
+	other protocols. Default: aware.
+
+	<tag><label id="ospf-graceful-restart-time">graceful restart time <m/num/</tag>
+	The restart time is announced in the Grace-LSA and specifies how long
+	neighbors should wait for proper end of the graceful restart before
+	exiting helper mode prematurely. Default: 120 seconds.
+
 	<tag><label id="ospf-area">area <M>id</M></tag>
 	This defines an OSPF area with given area ID (an integer or an IPv4
 	address, similarly to a router ID). The most important area is the
diff --git a/doc/reply_codes b/doc/reply_codes
index 3a7f2c90..02f4e656 100644
--- a/doc/reply_codes
+++ b/doc/reply_codes
@@ -33,6 +33,7 @@ Reply codes of BIRD command-line interface
 0022	Undo scheduled
 0023	Evaluation of expression
 0024	Graceful restart status report
+0025	Graceful restart ordered
 
 1000	BIRD version
 1001	Interface list