draft-ietf-grow-bmp-adj-rib-out.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
        <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
        <!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
        <!ENTITY IANA_STAT_ADJRIBOUT_PRE "14">
        <!ENTITY IANA_STAT_ADJRIBOUT_POST "15">
        <!ENTITY IANA_STAT_ADJRIBOUT_PER_SAFI_PRE "16">
        <!ENTITY IANA_STAT_ADJRIBOUT_PER_SAFI_POST "17">
        <!ENTITY IANA_PEER_INFO_TLV_ADMIN_LABEL "4">
        ]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std" docName="draft-ietf-grow-bmp-adj-rib-out-08"
     ipr="trust200902" submissionType="IETF" updates="7854">

    <front>
        <title abbrev="BMP Adj-RIB-Out">
            Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP)</title>

        <author fullname="Tim Evens" initials="T" surname="Evens">
            <organization>Cisco Systems</organization>

            <address>

                <postal>
                    <street>2901 Third Avenue, Suite 600</street>
                    <city>Seattle</city>
                    <region>WA</region>
                    <code>98121</code>
                    <country>USA</country>
                </postal>

                <email>tievens@cisco.com</email>

            </address>
        </author>

        <author fullname="Serpil Bayraktar" initials="S" surname="Bayraktar">
            <organization>Cisco Systems</organization>

            <address>

                <postal>
                    <street>3700 Cisco Way</street>
                    <city>San Jose</city>
                    <region>CA</region>
                    <code>95134</code>
                    <country>USA</country>
                </postal>

                <email>serpil@cisco.com</email>

            </address>
        </author>

        <author fullname="Paolo Lucente" initials="P" surname="Lucente">
            <organization>NTT Communications</organization>

            <address>

                <postal>
                    <street>Siriusdreef 70-72</street>
                    <city>Hoofddorp</city>
                    <code>2132</code>
                    <region>WT</region>
                    <country>NL</country>
                </postal>

                <email>paolo@ntt.net</email>

            </address>
        </author>

        <author fullname="Penghui Mi" initials="P" surname="Mi">
            <organization>Tencent</organization>

            <address>

                <postal>
                    <street>Tengyun Building,Tower A ,No. 397 Tianlin Road</street>
                    <city>Shanghai</city>
                    <code>200233</code>
                    <region></region>
                    <country>China</country>
                </postal>

                <email>kevinmi@tencent.com</email>

            </address>
        </author>

        <author fullname="Shunwan Zhuang" initials="S" surname="Zhuang">
            <organization>Huawei</organization>

            <address>

                <postal>
                    <street>Huawei Bld., No.156 Beiqing Rd.</street>
                    <city>Beijing</city>
                    <code>100095</code>
                    <region></region>
                    <country>China</country>
                </postal>

                <email>zhuangshunwan@huawei.com</email>

            </address>
        </author>


        <date year="2019"/>

        <area>General</area>

        <workgroup>Global Routing Operations</workgroup>
        <keyword>BGP</keyword>
        <keyword>BMP</keyword>
        <keyword>adj-rib-out</keyword>

        <abstract>
            <t>
                The BGP Monitoring Protocol (BMP) defines access to only the Adj-RIB-
                In Routing Information Bases (RIBs).  This document updates the BGP
                Monitoring Protocol (BMP) RFC 7854 by adding access to the Adj-RIB-
                Out RIBs. It adds a new flag to the peer header to distinguish Adj-
                RIB-In and Adj-RIB-Out.
            </t>
        </abstract>
    </front>

    <middle>
        <section title="Introduction" anchor="Introduction">
            <t>
                BGP Monitoring Protocol (BMP) defines monitoring of the received
                (e.g., Adj-RIB-In) Routing Information Bases (RIBs) per peer.  The
                Adj-RIB-In pre-policy conveys to a BMP receiver all RIB data before
                any policy has been applied.  The Adj-RIB-In post-policy conveys to a
                BMP receiver all RIB data after policy filters and/or modifications
                have been applied.  An example of pre-policy versus post-policy is
                when an inbound policy applies attribute modification or filters.
                Pre-policy would contain information prior to the inbound policy
                changes or filters of data. Post policy would convey the changed data
                or would not contain the filtered data.

                <vspace blankLines="1"/>

                Monitoring the received updates that the router received before any
                policy has been applied is the primary level of monitoring for most
                use-cases.  Inbound policy validation and auditing is the primary
                use-case for enabling post-policy monitoring.

                <vspace blankLines="1"/>

                In order for a BMP receiver to receive any BGP data, the BMP sender
                (e.g., router) needs to have an established BGP peering session and
                actively be receiving updates for an Adj-RIB-In.

                <vspace blankLines="1"/>

                Being able to only monitor the Adj-RIB-In puts a restriction on what
                data is available to BMP receivers via BMP senders (e.g., routers).
                This is an issue when the receiving end of the BGP peer is not
                enabled for BMP or when it is not accessible for administrative
                reasons.  For example, a service provider advertises prefixes to a
                customer, but the service provider cannot see what it advertises via
                BMP. Asking the customer to enable BMP and monitoring of the Adj-RIB-In
                is not feasible.

                <vspace blankLines="1"/>

                BGP Monitoring Protocol (BMP) <xref target="RFC7854">RFC 7854</xref> only
                defines Adj-RIB-In being sent to BMP receivers. This document updates
                the per-peer header in <xref target="RFC7854">section 4.2 of</xref> by
		adding a new flag to distinguish Adj-RIB-In versus Adj-RIB-Out. BMP
		senders use the new flag to send either Adj-RIB-In or Adj-RIB-Out.

                <vspace blankLines="1"/>

                Adding Adj-RIB-Out provides the ability for a BMP sender to send to 
                BMP receivers what it advertises to BGP peers, which can be used for
                outbound policy validation and to monitor routes that were advertised.
            </t>
        </section>

        <section title="Terminology">
            <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">RFC 2119</xref>
		<xref target="RFC8174">RFC 8174</xref> when, and only when, they
		appear in all capitals, as shown here.
            </t>
        </section>

        <section title="Definitions">
            <t>
                <list style="symbols">
                    <t>
                        Adj-RIB-Out: As defined in <xref target="RFC4271"/>, "The Adj-RIBs-Out contains
                        the routes for advertisement to specific peers by means of the
                        local speaker's UPDATE messages."
                    </t>

                    <t>
                        Pre-Policy Adj-RIB-Out: The result before applying the outbound
                        policy to an Adj-RIB-Out. This normally would match what is in the
                        local RIB.
                    </t>

                    <t>
                        Post-Policy Adj-RIB-Out: The result of applying outbound policy to
                        an Adj-RIB-Out. This MUST convey to the BMP receiver what is actually
			transmitted to the peer.
                    </t>
                </list>
            </t>
        </section>

        <section title="Per-Peer Header" anchor="PeerFlags">
            <t>
                The per-peer header has the same structure and flags as defined in
                <xref target="RFC7854">section 4.2 of</xref> with the following O flag
		addition:
            </t>
            <figure align="center">
                <artwork align="center"><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V|L|A|O| Resv  |
+-+-+-+-+-+-+-+-+
]]></artwork>
            </figure>

            <t>
                <list style="symbols">
                    <t>
                        The O flag indicates Adj-RIB-In if set to 0 and Adj-RIB-Out if
                        set to 1.
                    </t>
                </list>

                <vspace blankLines="1"/>

                The existing flags are defined in <xref target="RFC7854">section 4.2 of</xref> and
		the remaining bits are reserved for future use.  They MUST be transmitted as 0 and
		their values MUST be ignored on receipt.

                <vspace blankLines="1"/>
                When the O flag is set to 1, the following fields in the Per-Peer Header are
		redefined:

                <list style="symbols">
                    <t>
                        Peer Address: The remote IP address associated with the TCP
                        session over which the encapsulated PDU is sent.
                    </t>
                    <t>
                        Peer AS: The Autonomous System number of the peer to which the
                        encapsulated PDU is sent.
                    </t>
                    <t>
                        Peer BGP ID: The BGP Identifier of the peer to which the
                        encapsulated PDU is sent.
                    </t>
                    <t>
			Timestamp: The time when the encapsulated routes were advertised
      			(one may also think of this as the time when they were installed
      			in the Adj-RIB-Out), expressed in seconds and microseconds since
      			midnight (zero hour), January 1, 1970 (UTC).  If zero, the time is
			unavailable. Precision of the timestamp is implementation-dependent.
                    </t>
                </list>
            </t>
        </section>

        <section title="Adj-RIB-Out">
            <section title="Post-Policy">
                <t>
                    The primary use-case in monitoring Adj-RIB-Out is to monitor the
                    updates transmitted to a BGP peer after outbound policy has been
                    applied. These updates reflect the result after modifications and
                    filters have been applied (e.g., Adj-RIB-Out Post-Policy). Some
                    attributes are set when the BGP message is transmitted,
                    such as next-hop. Adj-RIB-Out Post-Policy MUST convey to the BMP
		    receiver what is actually transmitted to the peer.

                    <vspace blankLines="1"/>

                    The L flag MUST be set to 1 to indicate post-policy.
                </t>
            </section>

            <section title="Pre-Policy">
                <t>
                    Similarly to Adj-RIB-In policy validation, pre-policy Adj-RIB-Out can
		    be used to validate and audit outbound policies. For example, a
		    comparison between pre-policy and post-policy can be used to validate
		    the outbound policy.

                    <vspace blankLines="1"/>

                    Depending on BGP peering session type (IBGP, IBGP route reflector client,
                    EBGP, BGP confederations, Route Server Client) the candidate routes that
                    make up the Pre-Policy Adj-RIB-Out do not contain all local-rib routes.
                    Pre-Policy Adj-RIB-Out conveys only routes that are available based on
                    the peering type.  Post-Policy represents the filtered/changed routes
                    from the available routes.

                    <vspace blankLines="1"/>

                    Some attributes are set only during transmission of the BGP message,
                    i.e., Post-Policy.  It is common that next-hop may be null, loopback, or
                    similar during pre-policy phase. All mandatory attributes, such as next-hop,
                    MUST be either ZERO or have an empty length if they are unknown at the
                    Pre-Policy phase completion.  The BMP receiver will treat zero or empty
                    mandatory attributes as self-originated.

                    <vspace blankLines="1"/>

                    The L flag MUST be set to 0 to indicate pre-policy.
                </t>

            </section>


        </section>

        <section title="BMP Messages">
            <t>
                Many BMP messages have a per-peer header but some are not applicable
                to Adj-RIB-In or Adj-RIB-Out monitoring, such as peer up and down notifications.
                Unless otherwise defined, the O flag should be set to 0 in the per-peer header
                in BMP messages.
            </t>

            <section title="Route Monitoring and Route Mirroring">
                <t>
                    The O flag MUST be set accordingly to indicate if the route monitor
                    or route mirroring message conveys Adj-RIB-In or Adj-RIB-Out.
                </t>
            </section>

            <section title="Statistics Report" anchor="StatisticsReport">
                <t>
                    The Statistics report message has a Stat Type field to indicate the
                    statistic carried in the Stat Data field. Statistics report messages
                    are not specific to Adj-RIB-In or Adj-RIB-Out and MUST have the O
                    flag set to zero. The O flag SHOULD be ignored by the BMP receiver.

                    <vspace blankLines="1"/>
                    The following new statistic types are added:

                    <list style="symbols">
                        <t>
                            Stat Type = &IANA_STAT_ADJRIBOUT_PRE;: (64-bit Gauge)
                            Number of routes in Adj-RIBs-Out Pre-Policy.
                        </t>

                        <t>
                            Stat Type = &IANA_STAT_ADJRIBOUT_POST;: (64-bit Gauge)
                            Number of routes in Adj-RIBs-Out Post-Policy.
                        </t>

                        <t>
                            Stat Type = &IANA_STAT_ADJRIBOUT_PER_SAFI_PRE;: Number of routes
                            in per-AFI/SAFI Adj-RIB-Out Pre- Policy.  The value is structured
                            as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier
                            (SAFI), followed by a 64-bit Gauge.
                        </t>

                        <t>
                            Stat Type = &IANA_STAT_ADJRIBOUT_PER_SAFI_POST;: Number of routes in per-AFI/SAFI Adj-RIB-Out
                            Post-Policy.  The value is structured as: 2-byte Address Family
                            Identifier (AFI), 1-byte Subsequent Address Family Identifier
                            (SAFI), followed by a 64-bit Gauge.
                        </t>
                    </list>
                </t>
            </section>

            <section title="Peer Down and Up Notifications">
                <t>
                    Peer Up and Down notifications convey BGP peering session state to
                    BMP receivers.  The state is independent of whether or not route
                    monitoring or route mirroring messages will be sent for Adj-RIB-In,
                    Adj-RIB-Out, or both.  BMP receiver implementations SHOULD ignore the
                    O flag in Peer Up and Down notifications.
                </t>


                <section title="Peer Up Information" anchor="PeerUpInfoTlv">
                    <t>
                        The following Peer Up message Information TLV type is added:

                        <list style="symbols">
                            <t>
                                Type = &IANA_PEER_INFO_TLV_ADMIN_LABEL;: Admin Label.
                                The Information field contains a free-form UTF-8 string whose byte
				                length is given by the Information Length field.  The value is
				                administratively assigned.  There is no requirement to terminate
				                the string with null or any other character.

                                <vspace blankLines="1"/>

                                Multiple admin labels can be included in the Peer Up notification.  
                                When multiple admin labels are included the BMP receiver MUST preserve
                                their order.

                                <vspace blankLines="1"/>

                                The TLV is optional.
                            </t>
                        </list>
                    </t>
                </section>
            </section>

        </section>

        <section title="Other Considerations">
            <section title="Peer and Update Groups">
                <t>
                    Peer and update groups are used to group updates shared by many peers.
                    This is a level of efficiency in implementations, not a true
                    representation of what is conveyed to a peer in either Pre-Policy or
                    Post-Policy.

                    <vspace blankLines="1"/>

                    One of the use-cases to monitor Adj-RIB-Out Post-Policy is to validate and continually
                    ensure the egress updates match what is expected. For example, wholesale peers should
                    never have routes with community X:Y sent to them.  In this use-case, there may be
                    hundreds of wholesale peers but a single peer could have represented the group.

                    <vspace blankLines="1"/>

                    From a BMP perspective, this should be simple to include a group name in the Peer Up,
		            but it is more complex than that. BGP implementations have evolved to provide
		            comprehensive and structured policy grouping, such as session, AFI/SAFI, and
                    template-based group policy inheritances.

                    <vspace blankLines="1"/>

                    This level of structure and inheritance of polices does not provide a simple peer group
                    name or ID, such as wholesale peer.

                    <vspace blankLines="1"/>

                    Instead of requiring a group name to be used, a new administrative label
                     informational TLV (<xref target="PeerUpInfoTlv"/>) is added to the Peer Up
                    message.  These labels have administrative scope relevance.  For example, labels
                    "type=wholesale" and "region=west" could be used to monitor expected policies.

                    <vspace blankLines="1"/>

                    Configuration and assignment of labels to peers is BGP implementation specific.
                </t>
            </section>
	    <section title="Changes to existing BMP sessions">
		<t>
		    In case of any change that results in the alteration of behaviour of
		    an existing BMP session, ie. changes to filtering and table names, the
		    session MUST be bounced with a Peer DOWN/Peer UP sequence.
		</t>
	    </section>
        </section>

        <section title="Security Considerations">
            <t>
                The same considerations as in <xref target="RFC7854">section 11 of</xref> apply to this
		document. Implementations of this protocol SHOULD require to establish sessions with
		authorized and trusted monitoring devices. It is also believed that this document does
		not add any additional security considerations.
            </t>
        </section>

        <section title="IANA Considerations">
            <t>
                This document requests that IANA assign the following new parameters
                to the <eref
                          target="https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml">
                BMP parameters name space</eref>.
            </t>

            <section title="BMP Peer Flags">
                <t>
                    This document defines the following per-peer header flags (<xref target="PeerFlags"/>):

                    <list style="symbols">
                        <t>
                            Flag 3 as O flag: The O flag indicates Adj-RIB-In if set to 0 and Adj-RIB-Out if
                            set to 1.
                        </t>
                    </list>
                </t>
            </section>

            <section title="BMP Statistics Types">
                <t>
                    This document defines four statistic types for statistics
                    reporting (<xref target="StatisticsReport"/>):

                    <list style="symbols">
                        <t>
                            Stat Type = &IANA_STAT_ADJRIBOUT_PRE;: (64-bit Gauge)
                            Number of routes in Adj-RIBs-Out Pre-Policy.
                        </t>

                        <t>
                            Stat Type = &IANA_STAT_ADJRIBOUT_POST;: (64-bit Gauge)
                            Number of routes in Adj-RIBs-Out Post-Policy.
                        </t>

                        <t>
                            Stat Type = &IANA_STAT_ADJRIBOUT_PER_SAFI_PRE;: Number of routes
                            in per-AFI/SAFI Adj-RIB-Out Pre- Policy.  The value is structured
                            as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier
                            (SAFI), followed by a 64-bit Gauge.
                        </t>

                        <t>
                            Stat Type = &IANA_STAT_ADJRIBOUT_PER_SAFI_POST;: Number of routes in per-AFI/SAFI Adj-RIB-Out
                            Post-Policy.  The value is structured as: 2-byte Address Family
                            Identifier (AFI), 1-byte Subsequent Address Family Identifier
                            (SAFI), followed by a 64-bit Gauge.
                        </t>
                    </list>
                </t>
            </section>

            <section title="Peer Up Information TLV">
                <t>
                    This document defines the following BMP Peer Up Information
                    TLV types (<xref target="PeerUpInfoTlv"/>):

                    <list style="symbols">
                        <t>
                            Type = &IANA_PEER_INFO_TLV_ADMIN_LABEL;: Admin Label.
                            The Information field contains a free-form UTF-8 string whose byte
                            length is given by the Information Length field.  The value is
                            administratively assigned.  There is no requirement to terminate
                            the string with null or any other character.

                            <vspace blankLines="1"/>

                            Multiple admin labels can be included in the Peer Up notification.  
                            When multiple admin labels are included the BMP receiver MUST preserve
                            their order.

                            <vspace blankLines="1"/>

                            The TLV is optional.
                        </t>
                    </list>
                </t>
            </section>

        </section>

    </middle>

    <back>

        <references title="Normative References">
            &RFC2119;
            &RFC8174;

            <?rfc include="reference.RFC.4271.xml"?>
            <?rfc include="reference.RFC.7854.xml"?>

        </references>

        <section anchor="Acknowledgements" title="Acknowledgements" numbered="no">
            <t>
                The authors would like to thank John Scudder and Mukul Srivastava for their
		valuable input.
            </t>
        </section>

        <section anchor="Contributors" title="Contributors" numbered="no">
            <t>
                Manish Bhardwaj<vspace/>
                Cisco Systems<vspace/>
                3700 Cisco Way<vspace/>
                San Jose, CA 95134<vspace/>
                USA<vspace/>
                <vspace blankLines="1"/>
                Email: manbhard@cisco.com<vspace blankLines="1"/>
            </t>

            <t>
                Xianyuzheng<vspace/>
                Tencent<vspace/>
                Tencent Building, Kejizhongyi Avenue,<vspace/>
                Hi-techPark, Nanshan District,Shenzhen 518057, P.R.China<vspace/>
                <vspace blankLines="1"/>
            </t>


            <t>
                Weiguo<vspace/>
                Tencent<vspace/>
                Tencent Building, Kejizhongyi Avenue,<vspace/>
                Hi-techPark, Nanshan District,Shenzhen 518057, P.R.China<vspace/>

                <vspace blankLines="1"/>
            </t>

            <t>
                Shugang cheng<vspace/>
                H3C<vspace/>

                <vspace blankLines="1"/>
            </t>

        </section>

    </back>
</rfc>