rfc8671xml2.original.xml   rfc8671.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refer
ence.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refer
ence.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 category="std" docName="draft-ietf-grow-bmp-adj-rib-out-07"
ipr="trust200902" submissionType="IETF" updates="7854">
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<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</stre
et>
<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> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<postal> <rfc number="8671" xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
<street>Huawei Bld., No.156 Beiqing Rd.</street> docName="draft-ietf-grow-bmp-adj-rib-out-07" ipr="trust200902" consensus="t
<city>Beijing</city> rue"
<code>100095</code> submissionType="IETF" updates="7854" obsoletes="" xml:lang="en"
<region></region> tocInclude="true" symRefs="true" sortRefs="true" version="3">
<country>China</country>
</postal>
<email>zhuangshunwan@huawei.com</email> <!-- xml2rfc v2v3 conversion 2.27.1 -->
<front>
<title abbrev="BMP Adj-RIB-Out">
Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)</title>
</address> <!-- [rfced] *ADs, please review the new Section 7.2 and let us know if you
</author> approve this added text. This change was sent to us after the document
was approved for publication. You can view the added text in this diff file:
rfc8671-diff.html.
-->
<date year="2019"/> <seriesInfo name="RFC" value="8671" />
<area>General</area> <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>United States of America</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>United States of America</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/>
<country>China</country>
</postal>
<email>Penghui.Mi@gmail.com</email>
</address>
</author>
<author fullname="Shunwan Zhuang" initials="S" surname="Zhuang">
<organization>Huawei</organization>
<address>
<postal>
<street>Huawei Building, No.156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<region/>
<country>China</country>
</postal>
<email>zhuangshunwan@huawei.com</email>
</address>
</author>
<date month="October" year="2019"/>
<workgroup>Global Routing Operations</workgroup> <area>General</area>
<keyword>BGP</keyword> <workgroup>Global Routing Operations</workgroup>
<keyword>BMP</keyword> <keyword>BGP</keyword>
<keyword>adj-rib-out</keyword> <keyword>BMP</keyword>
<keyword>adj-rib-out</keyword>
<abstract> <abstract>
<t> <t>
The BGP Monitoring Protocol (BMP) defines access to only the Adj The BGP Monitoring Protocol (BMP) only defines access to the
-RIB- Adj-RIB-In Routing Information Bases (RIBs). This document
In Routing Information Bases (RIBs). This document updates the updates BMP (RFC 7854) by adding access to the Adj-RIB-Out
BGP RIBs. It also adds a new flag to the peer header to
Monitoring Protocol (BMP) RFC 7854 by adding access to the Adj-R distinguish between Adj-RIB-In and Adj-RIB-Out.
IB- </t>
Out RIBs. It adds a new flag to the peer header to distinguish A </abstract>
dj- </front>
RIB-In and Adj-RIB-Out. <middle>
</t> <section anchor="Introduction" numbered="true" toc="default">
</abstract> <name>Introduction</name>
</front>
<middle> <t>
<section title="Introduction" anchor="Introduction"> The BGP Monitoring Protocol (BMP) defines monitoring of the rece
<t> ived
BGP Monitoring Protocol (BMP) defines monitoring of the received (e.g., Adj-RIB-In) Routing Information Bases (RIBs) per peer.
(e.g., Adj-RIB-In) Routing Information Bases (RIBs) per peer. T The pre-policy Adj-RIB-In conveys to a BMP receiver all RIB data
he before
Adj-RIB-In pre-policy conveys to a BMP receiver all RIB data bef any policy has been applied. The post-policy Adj-RIB-In conveys
ore to a
any policy has been applied. The Adj-RIB-In post-policy conveys
to a
BMP receiver all RIB data after policy filters and/or modificati ons BMP receiver all RIB data after policy filters and/or modificati ons
have been applied. An example of pre-policy versus post-policy is have been applied. An example of pre-policy versus post-policy is
when an inbound policy applies attribute modification or filters . when an inbound policy applies attribute modification or filters .
Pre-policy would contain information prior to the inbound policy Pre-policy would contain information prior to the inbound policy
changes or filters of data. Post policy would convey the changed data changes or filters of data. Post-policy would convey the changed data
or would not contain the filtered data. or would not contain the filtered data.
</t>
<vspace blankLines="1"/> <t>
Monitoring the received updates that the router received before any Monitoring the received updates that the router received before any
policy has been applied is the primary level of monitoring for m ost policy has been applied is the primary level of monitoring for m ost
use-cases. Inbound policy validation and auditing is the primar use cases. Inbound policy validation and auditing are the prima
y ry
use-case for enabling post-policy monitoring. use cases for enabling post-policy monitoring.
<vspace blankLines="1"/> </t>
<t>
In order for a BMP receiver to receive any BGP data, the BMP sen der In order for a BMP receiver to receive any BGP data, the BMP sen der
(e.g., router) needs to have an established BGP peering session and (e.g., router) needs to have an established BGP peering session and
actively be receiving updates for an Adj-RIB-In. actively be receiving updates for an Adj-RIB-In.
<vspace blankLines="1"/> </t>
<t>
Being able to only monitor the Adj-RIB-In puts a restriction on what 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., router s). data is available to BMP receivers via BMP senders (e.g., router s).
This is an issue when the receiving end of the BGP peer is not 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 enabled for BMP or when it is not accessible for administrative
reasons. For example, a service provider advertises prefixes to a reasons. For example, a service provider advertises prefixes to a
customer, but the service provider cannot see what it advertises via 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 BMP. Asking the customer to enable BMP and monitoring of the Adj -RIB-In
is not feasible. are not feasible.
<vspace blankLines="1"/> </t>
<t>
BGP Monitoring Protocol (BMP) <xref target="RFC7854">RFC 7854</x ref> only BMP <xref target="RFC7854" format="default"/> only
defines Adj-RIB-In being sent to BMP receivers. This document up dates defines Adj-RIB-In being sent to BMP receivers. This document up dates
the per-peer header in <xref target="RFC7854">section 4.2 of</xr the per-peer header defined in <xref target="RFC7854"
ef> by sectionFormat="of" section="4.2" /> by
adding a new flag to distinguish Adj-RIB-In versus Adj-RIB-Out. B adding a new flag to distinguish between Adj-RIB-In and Adj-RIB-O
MP ut. BMP
senders use the new flag to send either Adj-RIB-In or Adj-RIB-Out . senders use the new flag to send either Adj-RIB-In or Adj-RIB-Out .
<vspace blankLines="1"/> </t>
<t>
Adding Adj-RIB-Out provides the ability for a BMP sender to send to 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 BMP receivers what it advertises to BGP peers, which can be used for
outbound policy validation and to monitor routes that were adver tised. outbound policy validation and to monitor routes that were adver tised.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<name>Terminology</name>
<section title="Terminology"> <t>
<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"MAY", and "OPTIONAL" in this document are to be interpreted as RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119">RFC 2119</xref> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<xref target="RFC8174">RFC 8174</xref> when, and only when, they be interpreted as
appear in all capitals, as shown here. described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
</t> when, and only when, they appear in all capitals, as shown here.
</section> </t>
<section title="Definitions"> </section>
<t> <section numbered="true" toc="default">
<list style="symbols"> <name>Definitions</name>
<t>
Adj-RIB-Out: As defined in <xref target="RFC4271"/>, "Th <dl newline="true" spacing="normal">
e Adj-RIBs-Out contains <dt>Adj-RIB-Out</dt>
<dd>As defined in <xref target="RFC4271" format="default"/>, "The Adj-RI
Bs-Out contains
the routes for advertisement to specific peers by means of the the routes for advertisement to specific peers by means of the
local speaker's UPDATE messages." local speaker's UPDATE messages."</dd>
</t>
<t> <dt>Pre-policy Adj-RIB-Out</dt>
Pre-Policy Adj-RIB-Out: The result before applying the o <dd>The result before applying the outbound policy to an
utbound Adj-RIB-Out. This normally would match what is in the local RIB.</dd>
policy to an Adj-RIB-Out. This normally would match what
is in the
local RIB.
</t>
<t> <dt>Post-policy Adj-RIB-Out</dt>
Post-Policy Adj-RIB-Out: The result of applying outbound <dd>The result of applying outbound policy to an Adj-RIB-Out. This
policy to <bcp14>MUST</bcp14> convey to the BMP receiver what is actually
an Adj-RIB-Out. This MUST convey to the BMP receiver wha transmitted to the peer.</dd>
t is actually
transmitted to the peer.
</t>
</list>
</t>
</section>
<section title="Per-Peer Header" anchor="PeerFlags"> </dl>
<t>
</section>
<section anchor="PeerFlags" numbered="true" toc="default">
<name>Per-Peer Header</name>
<t>
The per-peer header has the same structure and flags as defined in The per-peer header has the same structure and flags as defined in
<xref target="RFC7854">section 4.2 of</xref> with the following <xref target="RFC7854" sectionFormat="of" section="4.2"/> with
O flag the addition of the O flag as shown here:
addition: </t>
</t> <artwork align="left" name="" type="" alt=""><![CDATA[
<figure align="center">
<artwork align="center"><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|V|L|A|O| Resv | |V|L|A|O| Resv |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <ul spacing="normal">
<li>
<t>
<list style="symbols">
<t>
The O flag indicates Adj-RIB-In if set to 0 and Adj-RIB- Out if The O flag indicates Adj-RIB-In if set to 0 and Adj-RIB- Out if
set to 1. set to 1.
</t> </li>
</list> </ul>
<t>
<vspace blankLines="1"/>
The existing flags are defined in <xref target="RFC7854">section The existing flags are defined in <xref target="RFC7854"
4.2 of</xref> and sectionFormat="of" section="4.2"/>, and
the remaining bits are reserved for future use. They MUST be tra the remaining bits are reserved for future use. They <bcp14>MUST
nsmitted as 0 and </bcp14> be transmitted as 0, and
their values MUST be ignored on receipt. their values <bcp14>MUST</bcp14> be ignored on receipt.
<vspace blankLines="1"/> </t>
When the O flag is set to 1, the following fields in the Per-Pee <t>
r Header are When the O flag is set to 1, the following fields in the per-pee
r header are
redefined: redefined:
<list style="symbols"> </t>
<t> <ul spacing="normal">
<li>
Peer Address: The remote IP address associated with the TCP Peer Address: The remote IP address associated with the TCP
session over which the encapsulated PDU is sent. session over which the encapsulated Protocol Data Unit
</t> (PDU) is sent.
<t> </li>
<li>
Peer AS: The Autonomous System number of the peer to whi ch the Peer AS: The Autonomous System number of the peer to whi ch the
encapsulated PDU is sent. encapsulated PDU is sent.
</t> </li>
<t> <li>
Peer BGP ID: The BGP Identifier of the peer to which the Peer BGP ID: The BGP Identifier of the peer to which the
encapsulated PDU is sent. encapsulated PDU is sent.
</t> </li>
<t> <li>
Timestamp: The time when the encapsulated routes were adv ertised Timestamp: The time when the encapsulated routes were adv ertised
(one may also think of this as the time when they were in stalled (one may also think of this as the time when they were in stalled
in the Adj-RIB-Out), expressed in seconds and microsecond s since in the Adj-RIB-Out), expressed in seconds and microsecond s since
midnight (zero hour), January 1, 1970 (UTC). If zero, th e time is midnight (zero hour), January 1, 1970 (UTC). If zero, th e time is
unavailable. Precision of the timestamp is implementation unavailable. Precision of the timestamp is
-dependent. implementation-dependent.
</t> </li>
</list> </ul>
</t> </section>
</section> <section numbered="true" toc="default">
<name>Adj-RIB-Out</name>
<section title="Adj-RIB-Out"> <section numbered="true" toc="default">
<section title="Post-Policy"> <name>Post-policy</name>
<t> <t>
The primary use-case in monitoring Adj-RIB-Out is to monitor The primary use case in monitoring Adj-RIB-Out is to monitor
the the
updates transmitted to a BGP peer after outbound policy has been updates transmitted to a BGP peer after outbound policy has been
applied. These updates reflect the result after modification s and applied. These updates reflect the result after modification s and
filters have been applied (e.g., Adj-RIB-Out Post-Policy). S ome filters have been applied (e.g., post-policy Adj-RIB-Out). S ome
attributes are set when the BGP message is transmitted, attributes are set when the BGP message is transmitted,
such as next-hop. Adj-RIB-Out Post-Policy MUST convey to the BMP such as next hop. Post-policy Adj-RIB-Out <bcp14>MUST</bcp14 > convey to the BMP
receiver what is actually transmitted to the peer. receiver what is actually transmitted to the peer.
<vspace blankLines="1"/> </t> <t>
The L flag <bcp14>MUST</bcp14> be set to 1 to indicate post-
The L flag MUST be set to 1 to indicate post-policy. policy.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Pre-Policy"> <name>Pre-policy</name>
<t> <t>
Similarly to Adj-RIB-In policy validation, pre-policy Adj-RI Similar to Adj-RIB-In policy validation, pre-policy Adj-RIB-
B-Out can Out can
be used to validate and audit outbound policies. For example, a be used to validate and audit outbound policies. For example, a
comparison between pre-policy and post-policy can be used to validate comparison between pre-policy and post-policy can be used to validate
the outbound policy. the outbound policy.
<vspace blankLines="1"/> </t>
<t>
Depending on BGP peering session type (IBGP, IBGP route refl Depending on the BGP peering session type -- Internal BGP (I
ector client, BGP), IBGP route reflector client,
EBGP, BGP confederations, Route Server Client) the candidate External BGP (EBGP), BGP confederations, route server
routes that client -- the candidate routes that
make up the Pre-Policy Adj-RIB-Out do not contain all local- make up the pre-policy Adj-RIB-Out do not contain all
rib routes. local RIB routes.
Pre-Policy Adj-RIB-Out conveys only routes that are availabl Pre-policy Adj-RIB-Out conveys only routes that are availabl
e based on e based on
the peering type. Post-Policy represents the filtered/chang the peering type. Post-policy represents the filtered/chang
ed routes ed routes
from the available routes. from the available routes.
<vspace blankLines="1"/> </t>
<t>
Some attributes are set only during transmission of the BGP message, Some attributes are set only during transmission of the BGP message,
i.e., Post-Policy. It is common that next-hop may be null, i.e., post-policy. It is common that the next hop may be nu
loopback, or ll, loopback, or
similar during pre-policy phase. All mandatory attributes, s similar during the pre-policy phase. All mandatory attribute
uch as next-hop, s,
MUST be either ZERO or have an empty length if they are unkn such as next hop,
own at the <bcp14>MUST</bcp14> be either zero or have an empty length i
Pre-Policy phase completion. The BMP receiver will treat ze f they are unknown at the
ro or empty pre-policy phase completion. The BMP receiver will treat ze
ro or empty
mandatory attributes as self-originated. mandatory attributes as self-originated.
</t>
<t>
<vspace blankLines="1"/> The L flag <bcp14>MUST</bcp14> be set to 0 to indicate pre-p
olicy.
The L flag MUST be set to 0 to indicate pre-policy. </t>
</t> </section>
</section>
</section> <section numbered="true" toc="default">
<name>BMP Messages</name>
</section> <t>
Many BMP messages have a per-peer header, but some are not
<section title="BMP Messages"> applicable to Adj-RIB-In or Adj-RIB-Out monitoring, such as
<t> Peer Up and Down Notifications. Unless otherwise defined, the
Many BMP messages have a per-peer header but some are not applic O flag should be set to 0 in the per-peer header in BMP
able messages.
to Adj-RIB-In or Adj-RIB-Out monitoring, such as peer up and dow </t>
n notifications. <section numbered="true" toc="default">
Unless otherwise defined, the O flag should be set to 0 in the p <name>Route Monitoring and Route Mirroring</name>
er-peer header <t>
in BMP messages. The O flag <bcp14>MUST</bcp14> be set accordingly to indicat
</t> e if the route monitor
<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 . or route mirroring message conveys Adj-RIB-In or Adj-RIB-Out .
</t> </t>
</section> </section>
<section anchor="StatisticsReport" numbered="true" toc="default">
<section title="Statistics Report" anchor="StatisticsReport"> <name>Statistics Report</name>
<t> <t>
The Statistics report message has a Stat Type field to indic The Statistics Report message has a Stat Type field to indic
ate the ate the
statistic carried in the Stat Data field. Statistics report messages statistic carried in the Stat Data field. Statistics report messages
are not specific to Adj-RIB-In or Adj-RIB-Out and MUST have are not specific to Adj-RIB-In or Adj-RIB-Out and <bcp14>MUS
the O T</bcp14> have the O
flag set to zero. The O flag SHOULD be ignored by the BMP re flag set to zero. The O flag <bcp14>SHOULD</bcp14> be ignore
ceiver. d by the BMP receiver.
<vspace blankLines="1"/>
The following new statistic types are added:
<list style="symbols"> </t>
<t> <t>
Stat Type = &IANA_STAT_ADJRIBOUT_PRE;: (64-bit Gauge This document defines the following new statistics types:
)
Number of routes in Adj-RIBs-Out Pre-Policy.
</t>
<t> </t>
Stat Type = &IANA_STAT_ADJRIBOUT_POST;: (64-bit Gaug
e)
Number of routes in Adj-RIBs-Out Post-Policy.
</t>
<t> <ul spacing="normal">
Stat Type = &IANA_STAT_ADJRIBOUT_PER_SAFI_PRE;: Numb <li>
er of routes Stat Type = 14:
in per-AFI/SAFI Adj-RIB-Out Pre- Policy. The value Number of routes in pre-policy Adj-RIB-Out. This
is structured statistics type is 64-bit Gauge.
</li>
<li>
Stat Type = 15:
Number of routes in post-policy Adj-RIB-Out. This
statistics type is 64-bit Gauge.
</li>
<li>
Stat Type = 16: Number of routes
in per-AFI/SAFI pre-policy Adj-RIB-Out. The value i
s structured
as: 2-byte Address Family Identifier (AFI), 1-byte S ubsequent Address Family Identifier as: 2-byte Address Family Identifier (AFI), 1-byte S ubsequent Address Family Identifier
(SAFI), followed by a 64-bit Gauge. (SAFI), followed by a 64-bit Gauge.
</t> </li>
<li>
<t> Stat Type = 17: Number of routes in per-AFI/SAFI
Stat Type = &IANA_STAT_ADJRIBOUT_PER_SAFI_POST;: Num post-policy Adj-RIB-Out. The value is structured
ber of routes in per-AFI/SAFI Adj-RIB-Out as: 2-byte Address Family Identifier (AFI), 1-byte
Post-Policy. The value is structured as: 2-byte Add Subsequent Address Family Identifier (SAFI),
ress Family followed by a 64-bit Gauge.
Identifier (AFI), 1-byte Subsequent Address Family I </li>
dentifier </ul>
(SAFI), followed by a 64-bit Gauge. </section>
</t> <section numbered="true" toc="default">
</list> <name>Peer Up and Down Notifications</name>
</t> <t>
</section> Peer Up and Down Notifications convey BGP peering session st
ate to
<section title="Peer Down and Up Notifications">
<t>
Peer Up and Down notifications convey BGP peering session st
ate to
BMP receivers. The state is independent of whether or not r oute BMP receivers. The state is independent of whether or not r oute
monitoring or route mirroring messages will be sent for Adj- RIB-In, monitoring or route mirroring messages will be sent for Adj- RIB-In,
Adj-RIB-Out, or both. BMP receiver implementations SHOULD i Adj-RIB-Out, or both. BMP receiver implementations <bcp14>S
gnore the HOULD</bcp14> ignore the
O flag in Peer Up and Down notifications. O flag in Peer Up and Down Notifications.
</t> </t>
<section anchor="PeerUpInfoTlv" numbered="true" toc="default">
<section title="Peer Up Information" anchor="PeerUpInfoTlv"> <name>Peer Up Information</name>
<t> <t>
The following Peer Up message Information TLV type is ad This document defines the following Peer Up Information
ded: TLV type:
<list style="symbols"> </t>
<t> <ul spacing="normal">
Type = &IANA_PEER_INFO_TLV_ADMIN_LABEL;: Admin L <li>
abel. <t>
Type = 4: Admin Label.
The Information field contains a free-form UTF-8 string whose byte The Information field contains a free-form UTF-8 string whose byte
length is given by the Informatio n Length field. The value is length is given by the Informatio n Length field. The value is
administratively assigned. There is no requirement to terminate administratively assigned. There is no requirement to terminate
the string with null or any other character. the string with null or any other character.
<vspace blankLines="1"/> </t>
<t>
Multiple admin labels can be included in the Pee
r Up notification.
When multiple admin labels are included the BMP
receiver MUST preserve
their order.
<vspace blankLines="1"/> Multiple Admin Labels can be included in the
Peer Up Notification. When multiple Admin
Labels are included, the BMP receiver
<bcp14>MUST</bcp14> preserve their order.
The TLV is optional. </t>
</t> <t>
</list>
</t>
</section>
</section>
The Admin Label is optional.
</t>
</li>
</ul>
</section> </section>
</section>
<section title="Other Considerations"> </section>
<section title="Peer and Update Groups"> <section numbered="true" toc="default">
<t> <name>Other Considerations</name>
<section numbered="true" toc="default">
<name>Peer and Update Groups</name>
<t>
Peer and update groups are used to group updates shared by m any peers. Peer and update groups are used to group updates shared by m any peers.
This is a level of efficiency in implementations, not a true This is a level of efficiency in implementations, not a true
representation of what is conveyed to a peer in either Pre-P representation of what is conveyed to a peer in either pre-p
olicy or olicy or
Post-Policy. post-policy.
<vspace blankLines="1"/> </t>
<t>
One of the use-cases to monitor Adj-RIB-Out Post-Policy is t o validate and continually One of the use cases to monitor post-policy Adj-RIB-Out is t o validate and continually
ensure the egress updates match what is expected. For exampl e, wholesale peers should ensure the egress updates match what is expected. For exampl e, wholesale peers should
never have routes with community X:Y sent to them. In this never have routes with community X:Y sent to them. In
use-case, there may be this use case, there may be
hundreds of wholesale peers but a single peer could have rep hundreds of wholesale peers, but a single peer could have re
resented the group. presented the group.
<vspace blankLines="1"/> </t>
From a BMP perspective, this should be simple to include a g <t>
roup name in the Peer Up, From a BMP perspective, it should be simple to include a gro
up name in the Peer Up,
but it is more complex than that. BGP implementations have evolved to provide but it is more complex than that. BGP implementations have evolved to provide
comprehensive and structured policy grouping, such as comprehensive and structured policy grouping, such
session, AFI/SAFI, and as session, AFI/SAFI, and
template-based based group policy inheritances. template-based group policy inheritances.
<vspace blankLines="1"/>
</t>
<t>
This level of structure and inheritance of polices does not provide a simple peer group This level of structure and inheritance of polices does not provide a simple peer group
name or ID, such as wholesale peer. name or ID, such as wholesale peer.
<vspace blankLines="1"/> </t>
<t>
Instead of requiring a group name to be used, a new administ
rative 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 imple
mentation specific.
</t>
</section>
</section>
<section title="Security Considerations"> This document defines a new Admin Label type for Peer Up Information TLVs
<t> (<xref target="PeerUpInfoTlv" format="default"/>) that can be used instead of
The same considerations as in <xref target="RFC7854">section 11 requiring a group name.
of</xref> apply to this These labels have administrative scope
document. Implementations of this protocol SHOULD require to esta relevance. For example, labels "type=wholesale" and
blish sessions with "region=west" could be used to monitor expected policies.
authorized and trusted monitoring devices. It is also believed th
at this document does
not add any additional security considerations.
</t>
</section>
<section title="IANA Considerations"> </t>
<t> <t>
This document requests that IANA assign the following new parame
ters
to the <eref
target="https://www.iana.org/assignments/bmp-parameter
s/bmp-parameters.xhtml">
BMP parameters name space</eref>.
</t>
<section title="BMP Peer Flags"> Configuration and assignment of labels to peers are BGP impl
<t> ementation-specific.
This document defines the following per-peer header flags (< </t>
xref target="PeerFlags"/>): </section>
<list style="symbols"> <section numbered="true" toc="default">
<t> <name>Changes to Existing BMP Session</name>
Flag 3 as O flag: The O flag indicates Adj-RIB-In if <t>
set to 0 and Adj-RIB-Out if In case of any change that results in the alteration of behavior of
set to 1. an existing BMP session (i.e., changes to filtering and table names),
</t> the session <bcp14>MUST</bcp14> be bounced with a Peer Down/Peer Up se
</list> quence.
</t> </t>
</section> </section>
</section>
<section title="BMP Statistics Types"> <section numbered="true" toc="default">
<t> <name>Security Considerations</name>
This document defines four statistic types for statistics <t>
reporting (<xref target="StatisticsReport"/>): The considerations in <xref target="RFC7854"
sectionFormat="of" section="11"/> apply to this
document. Implementations of this protocol
<bcp14>SHOULD</bcp14> require establishing sessions with
authorized and trusted monitoring devices.
<list style="symbols"> It is also believed that this document does
<t> not add any additional security considerations.
Stat Type = &IANA_STAT_ADJRIBOUT_PRE;: (64-bit Gauge </t>
) </section>
Number of routes in Adj-RIBs-Out Pre-Policy.
</t>
<t> <section numbered="true" toc="default">
Stat Type = &IANA_STAT_ADJRIBOUT_POST;: (64-bit Gaug <name>IANA Considerations</name>
e)
Number of routes in Adj-RIBs-Out Post-Policy.
</t>
<t> <t>IANA has assigned the following new parameters
Stat Type = &IANA_STAT_ADJRIBOUT_PER_SAFI_PRE;: Numb to the <eref target="https://www.iana.org/assignments/bmp-parame
er of routes ters/">
in per-AFI/SAFI Adj-RIB-Out Pre- Policy. The value "BGP Monitoring Protocol (BMP) Parameters" registry</eref>.
is structured </t>
as: 2-byte Address Family Identifier (AFI), 1-byte S <section numbered="true" toc="default">
ubsequent Address Family Identifier <name>Addition to BMP Peer Flags Registry</name>
(SAFI), followed by a 64-bit Gauge. <t>IANA has made the following assignment for the per-peer header flag
</t> defined in <xref target="PeerFlags" format="default"/> of this
document:
</t>
<t> <table anchor="iana1" align="left">
Stat Type = &IANA_STAT_ADJRIBOUT_PER_SAFI_POST;: Num <name>Addition to the "BMP Peer Flags" Registry</name>
ber of routes in per-AFI/SAFI Adj-RIB-Out <thead>
Post-Policy. The value is structured as: 2-byte Add <tr>
ress Family <th>Flag</th>
Identifier (AFI), 1-byte Subsequent Address Family I <th>Description</th>
dentifier <th>Reference</th>
(SAFI), followed by a 64-bit Gauge. </tr>
</t> </thead>
</list> <tbody>
</t> <tr>
</section> <td>3</td>
<td>O flag</td>
<td>RFC 8671</td>
</tr>
</tbody>
</table>
<section title="Peer Up Information TLV"> </section>
<t>
This document defines the following BMP Peer Up Information
TLV types (<xref target="PeerUpInfoTlv"/>):
<list style="symbols"> <section numbered="true" toc="default">
<t> <name>Additions to BMP Statistics Types Registry</name>
Type = &IANA_PEER_INFO_TLV_ADMIN_LABEL;: Admin Label
.
The Information field contains a free-form UTF-8 str
ing whose byte
length is given by the Information Length field. Th
e value is
administratively assigned. There is no requirement
to terminate
the string with null or any other character.
<vspace blankLines="1"/> <t>IANA has made the following assignment for the four statistics types
defined in <xref target="StatisticsReport" format="default"/> of this
document:
</t>
Multiple admin labels can be included in the Peer Up <table anchor="iana2" align="left">
notification. <name>Additions to the "BMP Statistics Types" Registry</name>
When multiple admin labels are included the BMP rece <thead>
iver MUST preserve <tr>
their order. <th>Stat Type</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>14</td>
<td>Number of routes in pre-policy Adj-RIB-Out</td>
<td>RFC 8671</td>
</tr>
<tr>
<td>15</td>
<td>Number of routes in post-policy Adj-RIB-Out</td>
<td>RFC 8671</td>
</tr>
<tr>
<td>16</td>
<td>Number of routes in per-AFI/SAFI pre-policy Adj-RIB-Out</td>
<td>RFC 8671</td>
</tr>
<tr>
<td>17</td>
<td>Number of routes in per-AFI/SAFI post-policy Adj-RIB-Out</td>
<td>RFC 8671</td>
</tr>
</tbody>
</table>
<vspace blankLines="1"/> </section>
The TLV is optional. <section numbered="true" toc="default">
</t> <name>Addition to BMP Initiation Message TLVs Registry</name>
</list> <t>IANA has made the following assignment per
</t> <xref target="PeerUpInfoTlv"
</section> format="default"/> of this document:
</t>
</section> <table anchor="iana3" align="left">
<name>Addition to the "BMP Initiation Message TLVs" Registry</name>
<thead>
<tr>
<th>Type</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>4</td>
<td>Admin Label</td>
<td>RFC 8671</td>
</tr>
</tbody>
</table>
</middle> </section>
</section>
</middle>
<back>
<references>
<name>Normative References</name>
<back> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<references title="Normative References"> <xi:include
&RFC2119; href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
&RFC8174;
<?rfc include="reference.RFC.4271.xml"?> <xi:include
<?rfc include="reference.RFC.7854.xml"?> href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7854.xml"/>
</references> <xi:include
href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<section anchor="Acknowledgements" title="Acknowledgements" numbered="no </references>
"> <section anchor="Acknowledgements" numbered="false" toc="default">
<t> <name>Acknowledgements</name>
<t>
The authors would like to thank John Scudder and Mukul Srivastav a for their The authors would like to thank John Scudder and Mukul Srivastav a for their
valuable input. valuable input.
</t> </t>
</section> </section>
<section anchor="Contributors" numbered="false" toc="default">
<section anchor="Contributors" title="Contributors" numbered="no"> <name>Contributors</name>
<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> <t>The following individuals contributed to this document:
Xianyuzheng<vspace/> </t>
Tencent<vspace/>
Tencent Building, Kejizhongyi Avenue,<vspace/>
Hi-techPark, Nanshan District,Shenzhen 518057, P.R.China<vspace/
>
<vspace blankLines="1"/>
</t>
<t> <ul spacing="normal">
Weiguo<vspace/> <li>Manish Bhardwaj, Cisco Systems</li>
Tencent<vspace/>
Tencent Building, Kejizhongyi Avenue,<vspace/>
Hi-techPark, Nanshan District,Shenzhen 518057, P.R.China<vspace/
>
<vspace blankLines="1"/> <li>Xianyu Zheng, Tencent</li>
</t>
<t> <li>Wei Guo, Tencent</li>
Shugang cheng<vspace/>
H3C<vspace/>
<vspace blankLines="1"/> <li>Shugang Cheng, H3C</li>
</t> </ul>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 97 change blocks. 
562 lines changed or deleted 521 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/