draft-sas-idr-maxprefix-outbound.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC4234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4234.xml">
<!ENTITY nbsp    "&#160;">
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc strict="yes" ?>
<?rfc comments="no" ?>
<?rfc inline="no" ?>
<?rfc editing="no" ?>
<?rfc toc="yes" ?>
<?rfc tocompact="yes" ?>
<?rfc tocdepth="3" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std"
    ipr="trust200902"
    docName="draft-sas-idr-maxprefix-outbound-00"
    submissionType="IETF">

    <front>

        <title abbrev="BGP Maximum Prefix Limits Outbound">
            BGP Maximum Prefix Limits Outbound
        </title>

        <author fullname="Job Snijders" initials="J." surname="Snijders">
            <organization abbrev="NTT">NTT Ltd.</organization>

            <address>
                <postal>
                    <street>Theodorus Majofskistraat 100</street>
                    <code>1065 SZ</code>
                    <city>Amsterdam</city>
                    <country>The Netherlands</country>
                </postal>
                <email>job@ntt.net</email>
            </address>
        </author>

        <author fullname="Melchior Aelmans" initials="M." surname="Aelmans">
            <organization>Juniper Networks</organization>

            <address>
                <postal>
                    <street>Boeing Avenue 240</street>
                    <code>1119 PZ</code>
                    <city>Schiphol-Rijk</city>
                    <country>The Netherlands</country>
                </postal>

                <email>maelmans@juniper.net</email>
            </address>
        </author>

        <author fullname="Massimiliano Stucchi" initials="M." surname="Stucchi">
            <organization>Independent</organization>
            <address>
                <email>max@stucchi.ch</email>
            </address>
        </author>

        <date />
        <area>Routing</area>
        <workgroup>Inter-Domain Routing</workgroup>

        <keyword>BGP</keyword>
        <keyword>Prefix</keyword>

        <abstract>
            <t>
                This document describes mechanisms to limit the negative impact of <xref target="RFC7908">route leaks</xref> and/or resource exhaustion in BGP <xref target="RFC4271" /> implementations.
            </t>
        </abstract>
        <note title="Requirements Language">
            <t>
                The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.
            </t>
        </note>
    </front>
    <middle>
        <section title="Introduction">
            <t>
                This document describes mechanisms to reduce the negative impact of certain types of misconfigurations and/or resource exhaustions in BGP <xref target="RFC4271" /> operations.
                While <xref target="RFC4271" /> already described a method to tear down BGP sessions when certain thresholds are exceeded, some nuances in this specification were missing resulting in inconsistencies between BGP implementations.
                This document introduces a specification for "outbound maximum prefix limits".
            </t>
        </section>
<!--
        <section title="Application of Control Theory to BGP Operations">
            <t>
            </t>
        </section>
-->
        <section title="Outbound Maximum Prefix Limits">
            <t>
                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 post-policy 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". Implementations MAY support additional actions.
                The Hard Cease action is defined in <xref target="RFC8538" />.
                
                Reporting when thresholds have been exceeded is an implementation specific consideration, but SHOULD include methods such as Syslog <xref target="RFC5424"/>.
                By definition, Outbound Maximum Prefix Limits are Post-Policy.
            </t>
            <t>
                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 <xref target="RFC4271">Section 3.2</xref>.
                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.
            </t>
            <t>
                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.
            </t>
        </section>

        <section title="Considerations for Operations with Multi-Protocol BGP">
            <t>
            </t>
        </section>

        <section title="Considerations for soft thresholds">
            <t>
                describe soft and hard limits (warning vs teardown)
            </t>
        </section>

       <section title="Security Considerations">
           <t>
               Maximum Prefix Limits are an essential tool for routing operations and SHOULD be used to increase stability.
            </t>
        </section>
        <section title="IANA Considerations">
            <t>
                <!-- improve the names to make it clear which side does what -->
                This memo requests that IANA updates the name of subcode "Maximum Number of Prefixes Reached" to "Threshold exceeded: Maximum Number of Prefixes Received" in the "Cease NOTIFICATION message subcodes" registry under the "Border Gateway Protocol (BGP) Parameters" group.
            </t>
            <t>
                This memo requests that IANA assigns a new subcode named "Threshold exceeded: Maximum Number of Prefixes Send" in the "Cease NOTIFICATION message subcodes" registry under the "Border Gateway Protocol (BGP) Parameters" group.
            </t>
        </section>
        <section title="Acknowledgments">
            <t>
                The authors would like to thank Saku Ytti and John Heasley (NTT Ltd.), Jeff Haas, Colby Barth and John Scudder (Juniper Networks), Martijn Schmidt (i3D.net), Teun Vink (BIT), Sabri Berisha (eBay), Martin Pels (Quanza), Steven Bakker (AMS-IX), Aftab Siddiqui (ISOC), Yu Tianpeng, Ruediger Volk (Deutsche Telekom), Robert Raszuk (Bloomberg) and Jakob Heitz (Cisco) for their support, insightful review, and comments.
            </t>
        </section>
        <section title="Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION">
            <t>
                This section records the status of known implementations of the
                protocol defined by this specification at the time of posting of
                this Internet-Draft, and is based on a proposal described in
                RFC7942. The description of implementations in this
                section is intended to assist the IETF in its decision processes in
                progressing drafts to RFCs.  Please note that the listing of any
                individual implementation here does not imply endorsement by the
                IETF. Furthermore, no effort has been spent to verify the
                information presented here that was supplied by IETF contributors.
                This is not intended as, and must not be construed to be, a catalog
                of available implementations or their features. Readers are advised
                to note that other implementations may exist.
            </t>
            <t>
                The below table provides an overview (as of the moment of writing) of which vendors have produced implementation of inbound or outbound maximum prefix limits.
                Each table cell shows the applicable configuration keywords if the vendor implemented the feature.
            </t>
                <texttable anchor="table_ex" title="Maximum prefix limits capabilities per implementation" style="all">
                    <ttcol align="center" width="20%">Vendor</ttcol>
                    <ttcol align="center">Type A Pre-Policy</ttcol>
                    <ttcol align="center">Type B Post-Policy</ttcol>
                    <ttcol align="center">Outbound</ttcol>
                    <c>Cisco IOS XR</c><c></c><c>maximum-prefix</c><c></c>
                    <c>Cisco IOS XE</c><c></c><c>maximum-prefix</c><c></c>
                    <c>Juniper Junos OS</c><c>prefix-limit</c><c>accepted-prefix-limit, or prefix-limit combined with 'keep none'</c><c></c>
                    <c>Nokia SR OS</c><c>prefix-limit</c><c></c><c></c>
                    <c>NIC.CZ BIRD</c><c>'import keep filtered' combined with 'receive limit'</c><c>'import limit' or 'receive limit'</c><c>export limit</c>
                    <c>OpenBSD OpenBGPD</c><c>max-prefix</c><c></c><c></c>
                    <c>Arista EOS</c><c>maximum-routes</c><c>maximum-accepted-routes</c><c></c>
                    <c>Huawei VRPv5</c><c>peer route-limit</c><c></c><c></c>
                    <c>Huawei VRPv8</c><c>peer route-limit</c><c>peer route-limit accept-prefix</c><c></c>
                    <postamble>First presented by Snijders at <xref target="RIPE77"/></postamble>
                </texttable>
            </section>

            <section title="Appendix: Implementation Guidance">
            <t>
                1)
                make it clear who does what:
                if A sends too many prefixes to B
                A should see "ABC" in log
                B should see "DEF" in log
                to make it clear which of the two parties does what

                2)
                recommended by default automatically restart after between 15 and 30 minutes
            </t>
        </section>


    </middle>
    <back>
        <references title="Normative References">
            <?rfc include="reference.RFC.2119"?>
            <?rfc include="reference.RFC.8174"?>
            <?rfc include="reference.RFC.4271"?>
            <?rfc include="reference.RFC.8538"?>
        </references>
        <references title="Informative References">
            <?rfc include="reference.RFC.5424"?>
            <?rfc include="reference.RFC.7908"?>
            <reference anchor="RIPE77" target="https://ripe77.ripe.net/wp-content/uploads/presentations/59-RIPE77_Snijders_Routing_Policy_Architecture.pdf">
                <front>
                    <title>Robust Routing Policy Architecture</title>
                    <author surname="Snijders" fullname="Job Snijders">
                        <organization>NTT Ltd.</organization>
                    </author>
                    <date month="May" year="2018"/>
                </front>
            </reference>
        </references>
    </back>
</rfc>