dev@, https://datatracker.ietf.org/doc/draft-sa-grow-maxprefix/?include_text=1 Do the current FRR master branch have support for both o Type A Pre-Policy, o Type B Post-Policy, and o Outbound BGP Maximum Prefix Limits? 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. """ """ +-------------+----------------+-------------------------+----------+ | Vendor | Type A Pre- | Type B Post-Policy | Outbound | | | Policy | | | +-------------+----------------+-------------------------+----------+ | Cisco IOS | | maximum-prefix | | | XR | | | | +-------------+----------------+-------------------------+----------+ | Cisco IOS | | maximum-prefix | | | XE | | | | +-------------+----------------+-------------------------+----------+ | Juniper | prefix-limit | accepted-prefix-limit, | | | Junos OS | | or prefix-limit | | | | | combined with 'keep | | | | | none' | | +-------------+----------------+-------------------------+----------+ | Nokia SR OS | prefix-limit | | | +-------------+----------------+-------------------------+----------+ | NIC.CZ BIRD | 'import keep | 'import limit' or | export | | | filtered' | 'receive limit' | limit | | | combined with | | | | | 'receive | | | | | limit' | | | +-------------+----------------+-------------------------+----------+ | OpenBSD | max-prefix | | | | OpenBGPD | | | | +-------------+----------------+-------------------------+----------+ | Arista EOS | maximum-routes | maximum-accepted-routes | | +-------------+----------------+-------------------------+----------+ | Huawei | peer route- | | | | VRPv5 | limit | | | +-------------+----------------+-------------------------+----------+ | Huawei | peer route- | peer route-limit | | | VRPv8 | limit | accept-prefix | | +-------------+----------------+-------------------------+----------+ First presented by Snijders at [RIPE77] Table 1: Maximum prefix limits capabilities per implementation """