Question in relation to draft-sa-grow-maxprefix

Hansen, Christoffer christoffer at netravnen.de
Mon Jul 29 15:59:21 CEST 2019


bird-users@,

https://datatracker.ietf.org/doc/draft-sa-grow-maxprefix/?include_text=1

Do the current bird 1.6.4 and 2.0.4 releases *not* support any of these
mentioned scenarios?

Christoffer

"""
2.1.  Type A: Pre-Policy Inbound Maximum Prefix Limits

   The Adj-RIBs-In stores routing information learned from inbound
   UPDATE messages that were received from another BGP speaker
   Section 3.2 [RFC4271].  The Type A pre-policy limit uses the number
   of NLRIs per Address Family Identifier (AFI) per Subsequent Address
   Family Identifier (SAFI) as input into its threshold comparisons.
   For example, when an operator configures the Type A pre-policy limit
   for IPv4 Unicast to be 50 on a given EBGP session, and the other BGP
   speaker announces its 51st IPv4 Unicast NLRI, the session MUST be
   terminated.

   Type A pre-policy limits are particularly useful to help dampen the
   effects of full table route leaks and memory exhaustion when the
   implementation stores rejected routes.

2.2.  Type B: Post-Policy Inbound Maximum Prefix Limits

   RFC4271 describes a Policy Information Base (PIB) that contains local
   policies that can be applied to the information in the Routing
   Information Base (RIB).  The Type B post-policy limit uses the number
   of NLRIs per Address Family Identifier (AFI) per Subsequent Address
   Family Identifier (SAFI), after application of the Import Policy as
   input into its threshold comparisons.  For example, when an operator
   configures the Type B post-policy limit for IPv4 Unicast to be 50 on
   a given EBGP session, and the other BGP speaker announces a hundred
   IPv4 Unicast routes of which none are accepted as a result of the
   local import policy (and thus not considered for the Loc-RIB by the
   local BGP speaker), the session is not terminated.

   Type B post-policy limits are useful to help prevent FIB exhaustion
   and prevent accidental BGP session teardown due to prefixes not
   accepted by policy anyway.

3.  Outbound Maximum Prefix Limits

   An operator MAY configure a BGP speaker to terminate its BGP session
   with a neighbor when the number of address prefixes to be advertised
   to that neighbor exceeds a locally configured upper limit.  The BGP
   speaker then MUST send the neighbor a NOTIFICATION message with the
   Error Code Cease and the Error Subcode "Threshold reached: Maximum
   Number of Prefixes Send", and MAY support other actions.  Reporting
   when thresholds have been exceeded is an implementation specific
   consideration, but SHOULD include methods such as Syslog [RFC5424].
   By definition, Outbound Maximum Prefix Limits are Post-Policy.

   The Adj-RIBs-Out stores information selected by the local BGP speaker
   for advertisement to its neighbors.  The routing information stored
   in the Adj-RIBs-Out will be carried in the local BGP speaker's UPDATE
   messages and advertised to its neighbors Section 3.2 [RFC4271].  The
   Outbound Maximum Prefix Limit uses the number of NLRIs per Address
   Family Identifier (AFI) per Subsequent Address Family Identifier
   (SAFI), after application of the Export Policy, as input into its
   threshold comparisons.  For example, when an operator configures the
   Outbound Maximum Prefix Limit for IPv4 Unicast to be 50 on a given
   EBGP session, and were about to announce its 51st IPv4 Unicast NLRI
   to the other BGP speaker as a result of the local export policy, the
   session MUST be terminated.

   Outbound Maximum Prefix Limits are useful to help dampen the negative
   effects of a misconfiguration in local policy.  In many cases, it
   would be more desirable to tear down a BGP session rather than
   causing or propagating a route leak.
"""

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20190729/6b9a2afa/attachment.sig>


More information about the Bird-users mailing list