<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ 
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3392 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3392.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
<!ENTITY RFC5291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5291.xml">
<!ENTITY RFC5292 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5292.xml">
<!ENTITY RFC7606 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7606.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-keyur-idr-bgp-prefix-limit-orf-03" ipr="trust200902">
    <front>
        <title abbrev="Prefix Limit Based ORF for BGP-4">Prefix Limit Based ORF for BGP-4</title>
        <author fullname="Marco Marzetti" initials="M" surname="Marzetti">
            <organization>PCCW Global</organization>
            <address>
                <postal>
                    <street>Via Palma il Vecchio, 55</street>
                    <city>Chiuduno</city>
                    <region>BG</region>
                    <code>24060</code>
                    <country>Italy</country>
                </postal>
                <email>mmarzetti@pccwglobal.com</email>
            </address>
        </author>
        <author fullname="Keyur Patel" initials="K" surname="Patel">
            <organization>Arrcus, Inc</organization>
            <address>
                <postal>
                    <street></street>
                    <city></city>
                    <region></region>
                    <code></code>
                </postal>
                <email>keyur@arrcus.com</email>
            </address>
        </author>
        <author fullname="John Scudder" initials="J" surname="Scudder">
            <organization>Juniper Networks</organization>
            <address>
                <postal>
                    <street></street>
                    <city></city>
                    <region></region>
                    <code></code>
                </postal>
                <email>jgs@juniper.net</email>
            </address>
        </author>
        <author fullname="Jakob Heitz" initials="J" surname="Heitz">
            <organization>Cisco</organization>
            <address>
                <postal>
                    <street>170 W. Tasman Drive </street>
                    <city>San Jose</city>
                    <region>CA</region>
                    <code>95124</code>
                </postal>
                <email>jheitz@cisco.com</email>
            </address>
        </author>
        <author fullname="Job Snijders" initials="J" surname="Snijders">
            <organization abbrev="NTT">NTT Communications</organization>
            <address>
                <postal>
                    <street>Theodorus Majofskistraat 100</street>
                    <city>Amsterdam</city>
                    <code>1065 SZ</code>
                    <country>The Netherlands</country>
                </postal>
                <email>job@ntt.net</email>
            </address>
        </author>
        <date />
        <area>Routing Area</area>
        <workgroup>IDR</workgroup>
        <keyword>RFC</keyword>
        <keyword>Request for Comments</keyword>
        <keyword>I-D</keyword>
        <keyword>Internet-Draft</keyword>
        <keyword>Prefix limit</keyword>
        <keyword>ORF </keyword>
        <abstract>
            <t>
                The BGP specification allows for "the ability to impose an (locally configured) upper bound on the number of address prefixes the speaker is willing to accept from a neighbor".
                In this specification, we define a new Outbound Route Filter type for BGP, termed "Prefix Limit Outbound Route Filter", which the speaker can use to communicate that upper bound to its peer.
                The peer is then required to abide by the limit.
                This is expected to have benefits in terms of resource consumption and more importantly, transparency of operation.
            </t>
        </abstract>
    </front>
    <middle>
        <section title="Introduction">
            <t>
                The Cooperative Outbound Route Filtering Capability defined in
                <xref target="RFC5291" /> provides a mechanism for a BGP speaker to send to its BGP neighbor a set of Outbound Route Filters (ORFs) that can be used by its neighbor to filter its outbound routing updates to the speaker.
            </t>
            <t>
                This documents defines a new ORF-type for BGP, termed "Prefix Limit Outbound Route Filter (PrefixLimit ORF)", that can be used to perform Prefix Limit based route filtering.
                This filtering mechanism imposes a limit on a the number of unique prefixes that the BGP speaker can advertise to its neighbor.
            </t>
        </section>
        <section title="Requirements Language">
            <t>
                The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.
            </t>
        </section>
        <section title="Prefix Limit ORF-Type">
            <t>
                The Prefix Limit ORF-Type allows a BGP speaker to inform its neighbor of its prefix limits.
                That is, it provides a mechanism through which a BGP speaker can request its neighbor to limit the number of unique prefixes that neighbor will advertise to the BGP speaker.
            </t>
            <t>
                Conceptually a Prefix Limit ORF entry consists of the fields "Action, Match, Reserved, Prefix-Limit".
            </t>
            <t>
                <list>
                    <t>
                        Action is a two-bit field.
                        The definition and use of the Action field is described in
                        <xref target="RFC5291" />.
                    </t>
                    <t>
                        Match is a one-bit field.
                        The value of this field is 0 for PERMIT and 1 for DENY.
                        In the context of the Prefix Limit ORF-Type, DENY indicates that the BGP speaker sending the ORF will terminate the connection in the event that the Prefix Limit is exceeded.
                    </t>
                    <t>
                        Reserved is a 5-bit field.
                        The definition and use of the Reserved field is described in <xref target="RFC5291" />.
                    </t>
                    <t>
                        The "Prefix-Limit" is a four byte unsigned integer.
                        It states the maximum number of unique prefixes that the ORF sending BGP speaker is willing to accept from the ORF receiving BGP speaker.
                    </t>
                </list>
            </t>
        </section>
        <section title="Prefix Limit ORF encoding">
            <t>
                The value of the ORF-Type for the Prefix Limit ORF-Type is [TBD].
            </t>
            <t>
                A Prefix Limit ORF entry is encoded as follows.
                The "Action", "Match", and the "Reserved" field of the entry is encoded in the common part
                <xref target="RFC5291" />, and the remaining field of the entry is encoded in the "Type specific part" as follows.
                <figure>
                    <artwork>
              +--------------------------------------------------+
              |       Prefix-Limit  (4 octets)                   |
              +--------------------------------------------------+
                    </artwork>
                </figure>
            </t>
        </section>
        <section title="Capability Specification for Cooperative route filtering with Prefix Limit">
            <t>
                A BGP speaker signals its compliance with this specification by listing the PrefixLimit ORF type in the Cooperative Route Filtering Capability as defined in
                <xref target="RFC5291"></xref>.
            </t>
        </section>
        <section title="Rules for Prefix Limit ORF">
            <t>
                We describe the rules for PrefixLimit primarily in terms of the rules for the router which sends a PrefixLimit ORF to its peer, which we term the "sending speaker", and for the router which receives a PrefixLimit ORF from its peer, which we term the "receiving speaker".
                Note that a given router may be either a sending or receiving speaker, or both, with respect to any given peering session.
            </t>
            <t>
                A router which supports PrefixLimit ORF MUST keep track of the number of prefixes it has advertised to its peer -- when a new prefix is advertised, the count is incremented, and when a prefix is withdrawn, the count is decremented.
                A modification to the route for an already-advertised prefix does not change the count.
                We refer to this count as the "advertised prefix count" for the session.
                In effect, the advertised prefix count is equivalent to the size of the Adj-RIB-Out for the session.
            </t>
            <t>
                A router which supports PrefixLimit ORF MAY maintain a received prefix count for its peer, which tracks the number of prefixes it has accepted from the peer.
                In effect, the received route count is equivalent to the size of the Adj-RIB-In for the session.
                The use of such a count is elaborated in the following section.
            </t>
            <section title="Rules for Sending Speaker">
                <t>
                    If a BGP speaker (the sending speaker) is configured to bound the number of prefixes it is willing to accept from its neighbor, it MAY advertise the value of that upper bound to that neighbor using PrefixLimit ORF.
                    In this section and its subsection, when we refer to "the PrefixLimit" we are referring to the PrefixLimit value most recently advertised by the sending speaker to the receiving speaker.
                </t>
                <t>
                    If the sending speaker does not maintain a received prefix count, it is implicitly relying on its peer to correctly abide by this specification and no further action is required.
                    If the sending speaker does maintain a received prefix count, it MAY locally enforce the PrefixLimit, according to the following rules.
                </t>
                <section title="Enforcing the Prefix Limit">
                    <t>
                        When the sending speaker sends a PrefixLimit ORF which is less than its current received prefix count, it SHOULD wait for some interval before enforcing the new PrefixLimit.
                        The interval to be used is a matter of local policy.
                        Also, even if the PrefixLimit ORF is greater than or equal to the current received prefix count, the router may wish to wait for some interval before enforcing the new limit in order to allow for UPDATEs which may have been in flight prior to the receipt of the PrefixLimit ORF by the peer.
                        Subsequent to any such waiting period, the remaining rules in this section SHALL apply.
                    </t>
                    <t>
                        If the PrefixLimit is exceeded (either because of a route announced by the peer or because the peer failed to timely withdraw routes after the PrefixLimit is revised downward), the peer is in violation, and the sending speaker MAY take corrective action.
                        The router MAY also allow the received prefix count to exceed the PrefixLimit by some amount as a matter of local policy.
                    </t>
                    <t>
                        Corrective actions MAY include dropping the BGP session or refusing to accept new prefixes in excess of the PrefixLimit.
                    </t>
                    <t>
                        If the former option -- dropping the BGP session -- is chosen, the router MUST indicate this in advance by advertising its PrefixLimit ORF with the Match flag set to DENY.
                        Also, by default it SHOULD NOT automatically reestablish the session.
                    </t>
                    <t>
                        If the latter option -- refusing to accept new prefixes -- is chosen, the router MUST accept modifications to already-accepted prefixes, and it MUST accept withdrawals of already-accepted prefixes.
                        If prefixes are withdrawn, the received prefix count will drop below the announced PrefixLimit and new prefixes SHOULD be accepted, again up to but not exceeding the limit.
                        Prefixes which are refused MUST NOT contribute to the received prefix count.
                    </t>
                    <t>
                        We note that the option of refusing to accept new prefixes will likely lead to desynchronization of the BGP session and is a flawed solution at best; operator intervention will be required in order to restore synchronization (for example, through correction of routing policies and a subsequent route-refresh).
                    </t>
                </section>
            </section>
            <section title="Rules for Receiving Speaker">
                <t>
                    When a PrefixLimit ORF is received, the new Prefix Limit value in the ORF is considered to be the new maximum Prefix Limit for the neighbor.
                    In this section, when we refer to "the PrefixLimit" we are referring to the PrefixLimit value most recently received from the sending speaker by the receiving speaker.
                </t>
                <t>
                    If Match field is set to DENY the advertised Prefix-Limit value is purely informational and the receiving speaker SHOULD advertise the prefix even if doing so would cause its advertised prefix count to exceed the Prefix-Limit.
                </t>
                <t>
                    Else, if Match field is set to PERMIT, the receiving speaker MUST NOT advertise a prefix to its peer if doing so would cause its advertised prefix count to exceed the PrefixLimit.
                </t>
                <t>
                    The receiving speaker MAY take local action when its advertised prefix count approaches or reaches the PrefixLimit.
                    The nature of the action (logging, incrementing counters, etc) is a matter of local policy, as is the threshold at which the action occurs.                    
                </t>
                <t>
                    When the receiving speaker receives a PrefixLimit ORF with When-to-Refresh set to DEFER, it need not take any additional action unless its current advertised prefix count exceeds the new PrefixLimit.
                    In that case, it MUST take immediate steps to correct the violation.
                </t>
                <t>
                    Such steps MAY include withdrawing already-advertised prefixes so as to reduce the advertised prefix count to be less than or equal to the PrefixLimit.
                    The selection of which prefixes to withdraw is a matter of local policy.
                    Another option to correct the violation would be to drop the session; in this case the session SHOULD NOT be automatically reestablished.
                </t>
                <t>
                    When the receiving speaker receives a PrefixLimit ORF with When-to-Refresh set to IMMEDIATE, it behaves as given for DEFER but in addition advertises its Adj-RIB-Out as specified in <xref target="RFC5291" />.
                </t>
            </section>
        </section>
        <section title="Error handling">
            <t>
                ORFs provide information that guides future sending, but any malformed ORF is simply missed filtering information.
                If Prefix Limit ORF is malformed, then the Refresh messages shall simply be discarded.
            </t>
        </section>
        <section title="Security Considerations">
            <t>This extension to BGP does not change the underlying security issues.
                However, it does suggest a mechanism by which certain denial of service risks may be reduced.
            </t>
        </section>
        <section title="Acknowledgements">
            <t>
                The authors would like to thank ... for their valuable comments.
            </t>
        </section>
        <section anchor="IANA" title="IANA Considerations">
            <t>
                IANA is requested to assign value TBD (PrefixLimit ORF) in the "BGP Outbound Route Filtering (ORF) Types" subregistry under the "Border Gateway Protocol (BGP) Parameters" registry.
            </t>
        </section>
    </middle>
    <back>
        <references title="Normative References">
            <?rfc include="reference.RFC.2119.xml"?>
            <?rfc include="reference.RFC.5291.xml"?>
        </references>
    </back>
</rfc>
