rfc9069.original.xml   rfc9069.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
<!ENTITY rfc7911 PUBLIC '' <!DOCTYPE rfc [
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7911.xml'> <!ENTITY nbsp "&#160;">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference <!ENTITY zwsp "&#8203;">
.RFC.2119.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference <!ENTITY wj "&#8288;">
.RFC.8174.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.4271.xml">
<!ENTITY RFC7854 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.7854.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference
.RFC.5226.xml">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-grow-bmp-loc
<?rfc toc="yes"?> al-rib-12" number="9069" ipr="trust200902" submissionType="IETF" category="std"
<?rfc tocdepth="4"?> consensus="true" updates="7854" obsoletes="" xml:lang="en" tocInclude="true" toc
<?rfc symrefs="yes"?> Depth="4" symRefs="true" sortRefs="true" version="3">
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-grow-bmp-local-rib-12" ipr="trust200902" submissionType="IETF" updates="7854"
obsoletes="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRe
fs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.3.0 --> <!-- xml2rfc v2v3 conversion 3.3.0 -->
<front> <front>
<title abbrev="BMP Loc-RIB"> <title abbrev="BMP Loc-RIB">
Support for Local RIB in BGP Monitoring Protocol (BMP)</title> Support for Local RIB in the BGP Monitoring Protocol (BMP)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-grow-bmp-local-rib-12"/> <seriesInfo name="RFC" value="9069"/>
<author fullname="Tim Evens" initials="T" surname="Evens"> <author fullname="Tim Evens" initials="T" surname="Evens">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street>2901 Third Avenue, Suite 600</street> <street>2901 Third Avenue, Suite 600</street>
<city>Seattle</city> <city>Seattle</city>
<region>WA</region> <region>WA</region>
<code>98121</code> <code>98121</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>tievens@cisco.com</email> <email>tievens@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Serpil Bayraktar" initials="S" surname="Bayraktar"> <author fullname="Serpil Bayraktar" initials="S" surname="Bayraktar">
<organization>Cisco Systems</organization> <organization>Menlo Security</organization>
<address> <address>
<postal> <postal>
<street>3700 Cisco Way</street> <street>800 W El Camino Real, Suite 250</street>
<city>San Jose</city> <city>Mountain View</city>
<region>CA</region> <region>CA</region>
<code>95134</code> <code>94040</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>serpil@cisco.com</email> <email>serpil.bayraktar@menlosecurity.com</email>
</address> </address>
</author> </author>
<author fullname="Manish Bhardwaj" initials="M" surname="Bhardwaj"> <author fullname="Manish Bhardwaj" initials="M" surname="Bhardwaj">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street>3700 Cisco Way</street> <street>3700 Cisco Way</street>
<city>San Jose</city> <city>San Jose</city>
<region>CA</region> <region>CA</region>
<code>95134</code> <code>95134</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>manbhard@cisco.com</email> <email>manbhard@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Paolo Lucente" initials="P" surname="Lucente"> <author fullname="Paolo Lucente" initials="P" surname="Lucente">
<organization>NTT Communications</organization> <organization>NTT Communications</organization>
<address> <address>
<postal> <postal>
<street>Siriusdreef 70-72</street> <street>Siriusdreef 70-72</street>
<city>Hoofddorp</city> <city>Hoofddorp</city>
<code>2132</code> <code>2132</code>
<region>WT</region>
<country>NL</country> <country>NL</country>
</postal> </postal>
<email>paolo@ntt.net</email> <email>paolo@ntt.net</email>
</address> </address>
</author> </author>
<date year="2021"/> <date year="2022" month="February" />
<area>General</area> <area>General</area>
<workgroup>Global Routing Operations</workgroup> <workgroup>Global Routing Operations</workgroup>
<keyword>BGP</keyword> <keyword>BGP</keyword>
<keyword>BMP</keyword> <keyword>BMP</keyword>
<keyword>local-rib</keyword> <keyword>local-rib</keyword>
<keyword>loc-rib</keyword> <keyword>loc-rib</keyword>
<abstract> <abstract>
<t> <t>
The BGP Monitoring Protocol (BMP) defines access to local Routin g The BGP Monitoring Protocol (BMP) defines access to local Routin g
Information Bases (RIBs). This document updates BMP (RFC 7854) b y Information Bases (RIBs). This document updates BMP (RFC 7854) b y
adding access to the Local Routing Information Base (Loc-RIB), a s adding access to the Local Routing Information Base (Loc-RIB), a s
defined in RFC 4271. The Loc-RIB contains the routes that have b defined in RFC 4271. The Loc-RIB contains the routes that have b
een een selected by the local BGP speaker's Decision Process.
selected by the local BGP speaker's Decision Process.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" numbered="true" toc="default"> <section anchor="Introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
This document defines a mechanism to monitor the BGP Loc-RIB sta te This document defines a mechanism to monitor the BGP Loc-RIB sta te
of remote BGP instances without the need to establish BGP peerin g of remote BGP instances without the need to establish BGP peerin g
sessions. sessions.
BMP <xref target="RFC7854" format="default"/> does not define a method to send BMP <xref target="RFC7854" format="default"/> does not define a method to send
the BGP instance Loc-RIB. It does define in the BGP instance Loc-RIB.
<xref target="RFC7854" format="default">section 8.2 of</xref> lo
cally originated routes, It does define locally originated routes in <xref target="RFC785
but these routes are defined as the routes originated into BGP. 4" sectionFormat="of" section="8.2"/>,
For example, as but these routes are defined as the routes that originated into
defined by <xref target="RFC4271" format="default">Section 9.4 o BGP (e.g.,
f</xref>. Loc-RIB <xref target="RFC4271" sectionFormat="of" section="9.4"/>). Loc-
RIB
includes all selected received routes from BGP peers in addition to locally includes all selected received routes from BGP peers in addition to locally
originated routes. originated routes.
</t> </t>
<t> <t>
<xref target="FigAdjRibInLocRib" format="default"/> shows the fl ow of received routes from one or more BGP peers <xref target="FigAdjRibInLocRib" format="default"/> shows the fl ow of received routes from one or more BGP peers
into the Loc-RIB. into the Loc-RIB.
</t> </t>
<figure anchor="FigAdjRibInLocRib"> <figure anchor="FigAdjRibInLocRib">
<name>BGP peering Adj-RIBs-In into Loc-RIB</name> <name>BGP Peering Adj-RIBs-In into Loc-RIB</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
+------------------+ +------------------+ +------------------+ +------------------+
| Peer-A | | Peer-B | | Peer-A | | Peer-B |
/-- | | ---- | | --\ /-- | | ---- | | --\
| | Adj-RIB-In (Pre) | | Adj-RIB-In (Pre) | | | | Adj-RIB-In (Pre) | | Adj-RIB-In (Pre) | |
| +------------------+ +------------------+ | | +------------------+ +------------------+ |
| | | | | | | |
| Filters/Policy -| Filters/Policy -| | | Filters/Policy -| Filters/Policy -| |
| V V | | V V |
| +------------------+ +------------------+ | | +------------------+ +------------------+ |
skipping to change at line 141 skipping to change at line 132
| V V | | V V |
| +-----------------------------------------+ | | +-----------------------------------------+ |
| | Loc-RIB | | | | Loc-RIB | |
| +-----------------------------------------+ | | +-----------------------------------------+ |
| | | |
| ROUTER/BGP Instance | | ROUTER/BGP Instance |
\----------------------------------------------------/ \----------------------------------------------------/
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The following are some use-cases for Loc-RIB access: The following are some use cases for Loc-RIB access:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t> <t>
The Adj-RIB-In for a given peer Post-Policy may contain hundreds of The Adj-RIB-In for a given peer post-policy may contain hundreds of
thousands of routes, with only a handful of routes selec ted and installed thousands of routes, with only a handful of routes selec ted and installed
in the Loc-RIB after best-path selection. in the Loc-RIB after best-path selection.
Some monitoring applications, such as ones that need onl y to Some monitoring applications, such as those that need on ly to
correlate flow records to Loc-RIB entries, only need to collect correlate flow records to Loc-RIB entries, only need to collect
and monitor the routes that are actually selected and us ed. and monitor the routes that are actually selected and us ed.
</t> </t>
<t> <t>
Requiring the applications to collect all Adj-RIB-In Pos t-Policy Requiring the applications to collect all Adj-RIB-In pos t-policy
data forces the applications to receive a potentially data forces the applications to receive a potentially
large unwanted data set and to perform the BGP decision process large unwanted data set and to perform the BGP decision process
selection, which includes having access to the interior gateway selection, which includes having access to the interior gateway
protocol (IGP) next-hop metrics. While it is possible to obtain protocol (IGP) next-hop metrics. While it is possible to obtain
the IGP topology information using BGP Link-State (BGP-L the IGP topology information using BGP - Link State (BGP
S), -LS),
it requires the application to implement shortest path f it requires the application to implement Shortest Path F
irst (SPF) irst (SPF)
and possibly constrained shortest path first (CSPF) base and possibly Constrained Shortest Path First (CSPF) base
d on d on
additional policies. This is overly complex for such a additional policies. This is overly complex for such a
simple application that only needs to have access to the Loc-RIB. simple application that only needs to have access to the Loc-RIB.
</t> </t>
</li> </li>
<li> <li>
It is common to see frequent changes over many BGP peers , but It is common to see frequent changes over many BGP peers , but
those changes do not always result in the router's Loc-R IB those changes do not always result in the router's Loc-R IB
changing. The change in the Loc-RIB can have a direct im pact changing. The change in the Loc-RIB can have a direct im pact
on the forwarding state. It can greatly reduce time to on the forwarding state. It can greatly reduce the time to
troubleshoot and resolve issues if operators have the hi story of troubleshoot and resolve issues if operators have the hi story of
Loc-RIB changes. For example, a performance issue might have Loc-RIB changes. For example, a performance issue might have
been seen for only a duration of 5 minutes. Post-facto been seen for only a duration of 5 minutes. Post-facto
troubleshooting this issue without Loc-RIB history hides any troubleshooting this issue without Loc-RIB history hides any
decision based routing changes that might have happened decision-based routing changes that might have happened
during during
those five minutes. those 5 minutes.
</li> </li>
<li> <li>
Operators may wish to validate the impact of policies ap plied Operators may wish to validate the impact of policies ap plied
to Adj-RIB-In by analyzing the final decision made by th e to the Adj-RIB-In by analyzing the final decision made b y the
router when installing into the Loc-RIB. For example, in order router when installing into the Loc-RIB. For example, in order
to validate if multi-path prefixes are installed as expe to validate if multipath prefixes are installed as expec
cted ted
for all advertising peers, the Adj-RIB-In Post-Policy an for all advertising peers, the Adj-RIB-In post-policy an
d Loc-RIB d Loc-RIB
needs to be compared. This is only possible if the Loc-R need to be compared. This is only possible if the Loc-RI
IB B
is available. Monitoring the Adj-RIB-In for this router from is available. Monitoring the Adj-RIB-In for this router from
another router to derive the Loc-RIB is likely to not sh ow same another router to derive the Loc-RIB is likely to not sh ow the same
installed prefixes. For example, the received Adj-RIB-In will installed prefixes. For example, the received Adj-RIB-In will
be different if ADD-PATH <xref target="RFC7911" format=" default"/> be different if ADD-PATH <xref target="RFC7911" format=" default"/>
is not enabled or if maximum supported number of equal p aths is different is not enabled or if the maximum supported number of equ al paths is different
between Loc-RIB and advertised routes. between Loc-RIB and advertised routes.
</li> </li>
</ul> </ul>
<t> <t>
This document adds Loc-RIB to the BGP Monitoring Protocol and This document adds Loc-RIB to the BGP Monitoring Protocol and
replaces <xref target="RFC7854" format="default">Section 8.2 of< /xref> Locally Originated Routes. replaces <xref target="RFC7854" sectionFormat="of" section="8.2" /> ("Locally Originated Routes").
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Alternative Method to Monitor Loc-RIB</name> <name>Alternative Method to Monitor Loc-RIB</name>
<t> <t>
Loc-RIB is used to build Adj-RIB-Out when advertising routes to a Loc-RIB is used to build Adj-RIB-Out when advertising routes to a
peer. It is therefore possible to derive the Loc-RIB of a ro uter by peer. It is therefore possible to derive the Loc-RIB of a ro uter by
monitoring the Adj-RIB-In Pre-Policy from another router. monitoring the Adj-RIB-In pre-policy from another router.
This becomes overly complex and error prone when considering the number This becomes overly complex and error prone when considering the number
of peers being monitored per router. of peers being monitored per router.
</t> </t>
<t> <t>
</t> </t>
<figure anchor="FigCurLocRibMon"> <figure anchor="FigCurLocRibMon">
<name>Alternative method to monitor Loc-RIB</name> <name>Alternative Method to Monitor Loc-RIB</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" alt=""><![CDATA[
/------------------------------------------------------\ /------------------------------------------------------\
| ROUTER1 BGP Instance | | ROUTER1 BGP Instance |
| | | |
| +--------------------------------------------+ | | +--------------------------------------------+ |
| | Loc-RIB | | | | Loc-RIB | |
| +--------------------------------------------+ | | +--------------------------------------------+ |
| | | | | | | |
| +------------------+ +------------------+ | | +------------------+ +------------------+ |
| | Peer-ROUTER2 | | Peer-ROUTER3 | | | | Peer-ROUTER2 | | Peer-ROUTER3 | |
skipping to change at line 252 skipping to change at line 243
\------------------------/ \-------------------------/ \------------------------/ \-------------------------/
| | | |
v v v v
ROUTER2 BMP Feed ROUTER3 BMP Feed ROUTER2 BMP Feed ROUTER3 BMP Feed
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
The setup needed to monitor the Loc-RIB of a router requires another The setup needed to monitor the Loc-RIB of a router requires another
router with a peering session to the target router that is t o be router with a peering session to the target router that is t o be
monitored. As shown in <xref target="FigCurLocRibMon" format ="default"/>, the monitored. As shown in <xref target="FigCurLocRibMon" format ="default"/>, the
target router Loc-RIB is advertised via Adj-RIB-Out target router Loc-RIB is advertised via the Adj-RIB-Out
to the BMP router over a standard BGP peering session. The B MP to the BMP router over a standard BGP peering session. The B MP
router then forwards Adj-RIB-In Pre-Policy to the BMP receiv er. router then forwards the Adj-RIB-In pre-policy to the BMP re ceiver.
</t> </t>
<t> <t>
BMP lacking access to Loc-RIB introduces the need for additi onal A BMP lacking access to Loc-RIB introduces the need for addi tional
resources: resources:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
Requires at least two routers when only one router was to be Requires at least two routers when only one router was to be
monitored. monitored.
</li> </li>
<li> <li>
Requires additional BGP peering to collect the received upda tes Requires additional BGP peering to collect the received upda tes
when peering may have not even been required in the first when peering may not have even been required in the first
place. For example, virtual routing and forwarding (VRF) tab les place. For example, virtual routing and forwarding (VRF) tab les
with no peers, redistributed BGP-LS with no peers, and with no peers, redistributed BGP-LS with no peers, and
segment routing egress peer engineering where no segment routing egress peer engineering where no
peers have link-state address family enabled are all peers have link-state address family enabled are all
situations with no preexisting BGP peers. situations with no preexisting BGP peers.
</li> </li>
</ul> </ul>
<t> <t>
Many complexities are introduced when using a received Adj-R IB-In Many complexities are introduced when using a received Adj-R IB-In
to infer a router Loc-RIB: to infer a router Loc-RIB:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
Adj-RIB-Out received as Adj-RIB-In from another router may h ave Adj-RIB-Out received as Adj-RIB-In from another router may h ave
a policy applied that filters, generates aggregates, suppres ses a policy applied that generates aggregates, suppresses
more specific prefixes, manipulates attributes, or filters r outes. Not more specific prefixes, manipulates attributes, or filters r outes. Not
only does this invalidate the Loc-RIB view, it adds complexi ty only does this invalidate the Loc-RIB view, it adds complexi ty
when multiple BMP routers may have peering sessions to the s ame when multiple BMP routers may have peering sessions to the s ame
router. The BMP receiver user is left with the error-prone t ask of router. The BMP receiver user is left with the error-prone t ask of
identifying which peering session is the best representative of identifying which peering session is the best representative of
the Loc-RIB. the Loc-RIB.
</li> </li>
<li> <li>
BGP peering is designed to work between administrative domai ns BGP peering is designed to work between administrative domai ns
and therefore does not need to include internal system level and therefore does not need to include internal system-level
information of each peering router (e.g., the system name or information of each peering router (e.g., the system name or
version information). In order to derive the Loc-RIB of a ro uter, version information). In order to derive the Loc-RIB of a ro uter,
the router name or other system information is needed. The B MP the router name or other system information is needed. The B MP
receiver and user are forced to do some type of correlation using receiver and user are forced to do some type of correlation using
what information is available in the peering session (e.g., peering whatever information is available in the peering session (e. g., peering
addresses, autonomous system numbers, and BGP identifiers). addresses, autonomous system numbers, and BGP identifiers).
This leads to error-prone correlations. This leads to error-prone correlations.
</li> </li>
<li> <li>
Correlating BGP identifiers (BGP-ID) and session addresses t o a Correlating BGP identifiers (BGP-ID) and session addresses t o a
router requires additional data, such as router inventory. T his router requires additional data, such as router inventory. T his
additional data provides the BMP receiver the ability to map and additional data provides the BMP receiver the ability to map and
correlate the BGP-IDs and/or session addresses, but requires correlate the BGP-IDs and/or session addresses but requires
the the
BMP receiver to somehow obtain this data outside of BMP. How BMP receiver to somehow obtain this data outside of the BMP.
this How this
data is obtained and the accuracy of the data directly affec data is obtained and the accuracy of the data directly affec
ts the t the
integrity of the correlation. integrity of the correlation.
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", <bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>
", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this docum
ent are to be interpreted as
described in BCP 14 <xref target="RFC2119" format="default">RFC 2 119</xref> described in BCP 14 <xref target="RFC2119" format="default">RFC 2 119</xref>
<xref target="RFC8174" format="default">RFC 8174</xref> when, and only w hen, they <xref target="RFC8174" format="default">RFC 8174</xref> when, and only w hen, they
appear in all capitals, as shown here. appear in all capitals, as shown here.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Definitions</name> <name>Definitions</name>
<ul spacing="normal"> <dl>
<li>
BGP Instance: refers to an instance of BGP-4 <xref target <dt>BGP Instance:</dt><dd>Refers to an instance of BGP-4 <xref target="RFC4271"
="RFC4271" format="default"/> format="default"/>,
and considerations in <xref target="RFC7854" format="defa and considerations in <xref target="RFC7854" sectionForma
ult">section 8.1 of</xref> do apply to it. t="of" section="8.1"/> apply to it.</dd>
</li> <dt>Adj-RIB-In:</dt><dd>As defined in <xref target="RFC4271" format="default"
<li> />, "The Adj-RIBs-In contains
Adj-RIB-In: As defined in <xref target="RFC4271" format="default"/>,
"The Adj-RIBs-In contains
unprocessed routing information that has been advertised to the unprocessed routing information that has been advertised to the
local BGP speaker by its peers." This is also referred to as the local BGP speaker by its peers." This is also referred to as the
pre-policy Adj-RIB-In in this document. "pre-policy Adj-RIB-In" in this document.
</li> </dd>
<li> <dt>
Adj-RIB-Out: As defined in <xref target="RFC4271" format="default"/> Adj-RIB-Out:</dt><dd>As defined in <xref target="RFC4271" format="de
, "The Adj-RIBs-Out contains fault"/>, "The Adj-RIBs-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."
</li> </dd>
<li> <dt>
Loc-RIB: As defined in <xref target="RFC4271" format="default">secti
on 9.4 of</xref>, "The Loc-RIB Loc-RIB:</dt><dd>As defined in <xref target="RFC4271" sectionFormat=
"of" section="1.1"/>, "The Loc-RIB
contains the routes that have been selected by the local BGP speaker's Decision contains the routes that have been selected by the local BGP speaker's Decision
Process." Note that the Loc-RIB state as monitored through BMP might Process." Note that the Loc-RIB state as monitored through BMP might
also contain routes imported from other routing protocols such as an IGP, also contain routes imported from other routing protocols such as an IGP
or local static routes. or local static routes.
</li> </dd>
<li> <dt>
Pre-Policy Adj-RIB-Out: The result before applying the outbound Pre-Policy Adj-RIB-Out:</dt><dd>The result before applying the outbo
und
policy to an Adj-RIB-Out. This normally represents a similar view of the policy to an Adj-RIB-Out. This normally represents a similar view of the
Loc-RIB but may contain additional routes based on BGP peering confi guration. Loc-RIB but may contain additional routes based on BGP peering confi guration.
</li> </dd>
<li> <dt>
Post-Policy Adj-RIB-Out: The result of applying outbound policy to Post-Policy Adj-RIB-Out:</dt><dd> The result of applying the outboun
an Adj-RIB-Out. This MUST be what is actually sent to the peer. d policy to
</li> an Adj-RIB-Out. This <bcp14>MUST</bcp14> be what is actually sent
</ul> to the peer.
</section> </dd>
<section numbered="true" toc="default"> </dl>
<name>Per-Peer Header</name> </section>
<section anchor="PeerType" numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Peer Type</name> <name>Per-Peer Header</name>
<t> <section anchor="PeerType" numbered="true" toc="default">
A new peer type is defined for Loc-RIB to distinguish that it <name>Peer Type</name>
represents the router Loc-RIB, which may have a route distinguisher <t>
(RD). A new peer type is defined for Loc-RIB to indicate that it
<xref target="RFC7854" format="default">Section 4.2 of</xref> define represents the router Loc-RIB, which may have a route distinguish
s a Local Instance er (RD).
Peer type, which is for the case of non-RD peers that hav <xref target="RFC7854" sectionFormat="of" section="4.2"/> defines
e an instance a Local Instance
identifier. Peer type, which is for the case of non-RD peers that
</t> have an instance
<t> identifier.
This document defines the following new peer type: </t>
</t> <t>
<ul spacing="normal"> This document defines the following new peer type:
<li> </t>
Peer Type = 3: Loc-RIB Instance Peer
</li>
</ul>
</section>
<section anchor="PeerFlags" numbered="true" toc="default">
<name>Peer Flags</name>
<t>
If locally sourced routes are communicated
using BMP, they MUST be conveyed using the Loc-RIB instance pee
r type.
</t>
<t>
The per-peer header flags for Loc-RIB Instance Peer type are defined
as follows:
</t>
<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| | | | | | | |
+-+-+-+-+-+-+-+-+
]]></artwork>
<ul spacing="normal">
<li>
<t>
The F flag indicates that the Loc-RIB is filtered. This MUST be
set when a filter is applied to Loc-RIB routes sent to the BMP
collector.
</t> <ul spacing="normal">
<t> <li>Peer Type = 3: Loc-RIB Instance Peer
</li>
</ul>
</section>
<section anchor="PeerFlags" numbered="true" toc="default">
<name>Peer Flags</name>
<t>
If locally sourced routes are communicated
using BMP, they <bcp14>MUST</bcp14> be conveyed using the L
oc-RIB Instance Peer Type.
</t>
<t>
The per-peer header flags for the Loc-RIB Instance Peer Type are
defined
as follows:
</t>
<artwork align="center" name="" type="" alt=""><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| | | | | | | |
+-+-+-+-+-+-+-+-+
]]></artwork>
<ul spacing="normal">
<li>
<t>
The F flag indicates that the Loc-RIB is filtered. This <bcp1
4>MUST</bcp14> be
set when a filter is applied to Loc-RIB routes sent to the BM
P
collector.
</t>
<t>
The unused bits are reserved for future use. They <bcp14>MUST
</bcp14> be
transmitted as 0, and their values <bcp14>MUST</bcp14> be ign
ored on receipt.
</t>
</li>
</ul>
</section>
</section>
<section numbered="true" toc="default">
<name>Loc-RIB Monitoring</name>
<t>
The Loc-RIB contains all routes selected by the BGP Decision
Process as
described in <xref target="RFC4271" sectionFormat="of" sectio
n="9.1"/>. These
routes include those learned from BGP peers via its Adj-RIBs-
In post-policy, as
well as routes learned by other means as per <xref target="RF
C4271" sectionFormat="of" section="9.4"/>.
The unused bits are reserved for future use. They MUST be
transmitted as 0 and their values MUST be ignored on receipt.
</t>
</li>
</ul>
</section>
</section>
<section numbered="true" toc="default">
<name>Loc-RIB Monitoring</name>
<t>
The Loc-RIB contains all routes selected by the BGP Decision Proc
ess as
described in <xref target="RFC4271" format="default">section 9.1
of</xref>. These
routes include those learned from BGP peers via its Adj-RIBs-In P
ost-Policy, as
well as routes learned by other means as per <xref target="RFC427
1" format="default">section 9.4 of</xref>.
Examples of these include redistribution of routes from other pro tocols into BGP Examples of these include redistribution of routes from other pro tocols into BGP
or otherwise locally originated (i.e., aggregate routes). or those otherwise locally originated (i.e., aggregate routes).
</t> </t>
<t> <t>
As described in <xref target="FilterLocRib" format="default"/>, a subset of Loc-RIB routes As described in <xref target="FilterLocRib" format="default"/>, a subset of Loc-RIB routes
MAY be sent to a BMP collector by setting the F flag. <bcp14>MAY</bcp14> be sent to a BMP collector by setting the F flag.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Per-Peer Header</name> <name>Per-Peer Header</name>
<t> <t>
All peer messages that include a per-peer header as defined in All peer messages that include a per-peer header as defined in
<xref target="RFC7854" format="default">section 4.2 of</xref> <xref target="RFC7854" sectionFormat="of" section="4.2"/>
MUST use the following values: <bcp14>MUST</bcp14> use the following values:
</t> </t>
<ul spacing="normal"> <dl>
<li> <dt>
Peer Type: Set to 3 to indicate Loc-RIB Instance Peer. Peer Type:</dt><dd>Set to 3 to indicate Loc-RIB Instance Peer.
</li> </dd>
<li> <dt>
Peer Distinguisher: Zero filled if the Loc-RIB represents the Peer Distinguisher:</dt><dd>Zero-filled if the Loc-RIB represent
global instance. Otherwise set to the route distinguisher or s the
unique locally defined value of the particular instance the Loc- global instance. Otherwise, set to the route distinguisher or
RIB belongs to. unique locally defined value of the particular instance to which
</li> the Loc-RIB belongs.
<li> </dd>
Peer Address: Zero-filled. Remote peer address is not applicable
. <dt>
The V flag is not applicable with Loc-RIB Instance peer type Peer Address:</dt><dd> Zero-filled. The remote peer address is n
considering addresses are zero-filed. ot applicable.
</li> The V flag is not applicable with the Loc-RIB Instance Peer Type
<li> considering addresses are zero-filled.
Peer AS: Set to the primary router BGP autonomous system number </dd>
(ASN). <dt>
</li> Peer Autonomous System (AS):</dt><dd>Set to the primary router B
<li> GP autonomous system number (ASN).
Peer BGP ID: Set to the BGP instance global or RD (e.g., VRF) </dd>
specific router-id <xref target="RFC7854" format="default">secti <dt>
on 1.1 of</xref>. Peer BGP ID:</dt><dd> Set the ID to the router-id of the VRF ins
</li> tance if VRF is used; otherwise, set to the global instance router-id.
<li> </dd>
Timestamp: The time when the encapsulated routes were installed i <dt>
n Timestamp:</dt><dd>The time when the encapsulated routes were ins
talled in
the Loc-RIB, expressed in seconds and microseconds since midnight the Loc-RIB, expressed in seconds and microseconds since midnight
(zero hour), January 1, 1970 (UTC). If zero, the time is unavail able. (zero hour), January 1, 1970 (UTC). If zero, the time is unavail able.
Precision of the timestamp is implementation-dependent. Precision of the timestamp is implementation dependent.
</li> </dd>
</ul> </dl>
</section> </section>
<section anchor="PeerUpNotify" numbered="true" toc="default"> <section anchor="PeerUpNotify" numbered="true" toc="default">
<name>Peer Up Notification</name> <name>Peer Up Notification</name>
<t> <t>
Peer Up notifications follow <xref target="RFC7854" format="defa ult">section 4.10 of</xref> with the Peer Up notifications follow <xref target="RFC7854" sectionForma t="of" section="4.10"/> with the
following clarifications: following clarifications:
</t> </t>
<ul spacing="normal"> <dl>
<li> <dt>
Local Address: Zero-filled, local address is not applicable. Local Address:</dt><dd> Zero-filled; the local address is not ap
</li> plicable.
<li> </dd>
Local Port: Set to 0, local port is not applicable. <dt>
</li> Local Port:</dt><dd> Set to 0; the local port is not applicable.
<li> </dd>
Remote Port: Set to 0, remote port is not applicable. <dt>
</li> Remote Port:</dt><dd> Set to 0; the remote port is not applicabl
<li> e.
Sent OPEN Message: This is a fabricated BGP OPEN message. </dd>
Capabilities MUST include the 4-octet ASN and all necessary <dt>
capabilities to represent the Loc-RIB route monitoring messages. Sent OPEN Message:</dt><dd> This is a fabricated BGP OPEN messag
e.
Capabilities <bcp14>MUST</bcp14> include the 4-octet ASN and all
necessary
capabilities to represent the Loc-RIB Route Monitoring messages.
Only include capabilities if they will be used for Loc-RIB Only include capabilities if they will be used for Loc-RIB
monitoring messages. For example, if ADD-PATH is enabled for monitoring messages. For example, if ADD-PATH is enabled for
IPv6 and Loc-RIB contains additional paths, the ADD-PATH IPv6 and Loc-RIB contains additional paths, the ADD-PATH
capability should be included for IPv6. In the case of ADD-PATH , capability should be included for IPv6. In the case of ADD-PATH ,
the capability intent of advertise, receive or both can be ignor the capability intent of advertise, receive, or both can be igno
ed red
since the presence of the capability indicates enough that add- since the presence of the capability indicates enough that additional
paths will be used for IPv6. paths will be used for IPv6.
</li> </dd>
<li> <dt>
Received OPEN Message: Repeat of the same Sent Open Message. Th Received OPEN Message:</dt><dd> Repeat of the same sent OPEN mes
e sage. The
duplication allows the BMP receiver to parse the expected duplication allows the BMP receiver to parse the expected
received OPEN message as defined in <xref target="RFC7854" forma received OPEN message as defined in <xref target="RFC7854" secti
t="default">section 4.10 of</xref>. onFormat="of" section="4.10"/>.
</li> </dd>
</ul> </dl>
<section anchor="PeerUpInfoTlv" numbered="true" toc="default"> <section anchor="PeerUpInfoTlv" numbered="true" toc="default">
<name>Peer Up Information</name> <name>Peer Up Information</name>
<t> <t>
The following Peer Up information TLV type is added: The following Peer Up Information TLV type is added:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t> <t>Type = 3: VRF/Table Name. The Information field contains a
Type = 3: VRF/Table Name. The Information field contains a UTF-8 string whose value <bcp14>MUST</bcp14> be equal to the val
UTF-8 string whose value MUST be equal to the value of the VRF o ue of the VRF or
r
table name (e.g., RD instance name) being conveyed. The string size table name (e.g., RD instance name) being conveyed. The string size
MUST be within the range of 1 to 255 bytes. <bcp14>MUST</bcp14> be within the range of 1 to 255 bytes.
</t> </t>
<t> <t>
The VRF/Table Name TLV is optionally included to support impleme ntations The VRF/Table Name TLV is optionally included to support impleme ntations
that may not have defined a name. If a name is configured, it M UST that may not have defined a name. If a name is configured, it < bcp14>MUST</bcp14>
be included. The be included. The
default value of "global" MUST be used for the default Loc-RIB default value of "global" <bcp14>MUST</bcp14> be used for the de fault Loc-RIB
instance with a zero-filled distinguisher. instance with a zero-filled distinguisher.
If the TLV is included, then it <bcp14>MUST</bcp14> also be incl
If the TLV is included, then it MUST also be included in the Pee uded in the Peer
r Down notification. Down notification.
</t> </t>
</li> </li>
</ul> </ul>
<t>The Information field contains a
UTF-8 string whose value <bcp14>MUST</bcp14> be equal to the val
ue of the VRF or
table name (e.g., RD instance name) being conveyed. The string
size
<bcp14>MUST</bcp14> be within the range of 1 to 255 bytes.
</t>
<t>
The VRF/Table Name TLV is optionally included to support impleme
ntations
that may not have defined a name. If a name is configured, it <
bcp14>MUST</bcp14>
be included. The
default value of "global" <bcp14>MUST</bcp14> be used for the de
fault Loc-RIB
instance with a zero-filled distinguisher.
If the TLV is included, then it <bcp14>MUST</bcp14> also be incl
uded in the Peer Down notification.
</t>
<t> <t>
Multiple TLVs of the same type can be repeated as part of the same message, Multiple TLVs of the same type can be repeated as part of the same message,
for example to convey a filtered view of a VRF. A BMP rec eiver should append for example, to convey a filtered view of a VRF. A BMP re ceiver should append
multiple TLVs of the same type to a set in order to suppo rt alternate or multiple TLVs of the same type to a set in order to suppo rt alternate or
additional names for the same peer. If multiple strings a re included, their additional names for the same peer. If multiple strings a re included, their
ordering MUST be preserved when they are reported. ordering <bcp14>MUST</bcp14> be preserved when they are r eported.
</t> </t>
</section> </section>
</section> </section>
<section anchor="PeerDownReasonCode" numbered="true" toc="default"> <section anchor="PeerDownReasonCode" numbered="true" toc="default">
<name>Peer Down Notification</name> <name>Peer Down Notification</name>
<t> <t>
Peer Down notification MUST use reason code 6. Following the reason The Peer Down notification <bcp14>MUST</bcp14> use reason code 6. Fo
is data llowing the reason is data
in TLV format. The following Peer Down information TLV type i in TLV format. The following Peer Down Information TLV type i
s defined: s defined:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
Type = 3: VRF/Table Name. The Information field contains a Type = 3: VRF/Table Name. The Information field contains a
UTF-8 string whose value MUST be equal to the value of the VRF o r UTF-8 string whose value <bcp14>MUST</bcp14> be equal to the val ue of the VRF or
table name (e.g., RD instance name) being conveyed. The string size table name (e.g., RD instance name) being conveyed. The string size
MUST be within the range of 1 to 255 bytes. The VRF/Table Name <bcp14>MUST</bcp14> be within the range of 1 to 255 bytes. The V
informational TLV MUST be included if it was in t RF/Table Name
he Peer Up. informational TLV <bcp14>MUST</bcp14> be included
if it was in the Peer Up.
</li> </li>
</ul> </ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Route Monitoring</name> <name>Route Monitoring</name>
<t> <t>
Route Monitoring messages are used for initial synchronization of Route Monitoring messages are used for initial synchronization of
the Loc-RIB. They are also used to convey incremental Loc-RIB the Loc-RIB. They are also used to convey incremental Loc-RIB
changes. changes.
</t> </t>
<t> <t>
As defined in <xref target="RFC7854" format="default">section 4.6 of </xref>, "Following the As described in <xref target="RFC7854" sectionFormat="of" section="4 .6"/>, "Following the
common BMP header and per-peer header is a BGP Update PDU." common BMP header and per-peer header is a BGP Update PDU."
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>ASN Encoding</name> <name>ASN Encoding</name>
<t> <t>
Loc-RIB route monitor messages MUST use 4-byte ASN encoding as indic Loc-RIB Route Monitoring messages <bcp14>MUST</bcp14> use a 4-byte A
ated SN encoding as indicated
in <xref target="PeerUpNotify" format="default">Peer Up sent OPEN me in the <xref target="PeerUpNotify" format="default">Peer Up sent OPE
ssage</xref> capability. N message</xref> capability.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Granularity</name> <name>Granularity</name>
<t> <t>
State compression and throttling SHOULD be used by a BMP sender State compression and throttling <bcp14>SHOULD</bcp14> be used by a
to reduce the amount of route monitoring messages that are BMP sender
to reduce the amount of Route Monitoring messages that are
transmitted to BMP receivers. With state compression, only the transmitted to BMP receivers. With state compression, only the
final resultant updates are sent. final resultant updates are sent.
</t> </t>
<t> <t>
For example, prefix 192.0.2.0/24 is updated in the Loc-RIB 5 times For example, prefix 192.0.2.0/24 is updated in the Loc-RIB 5 times
within 1 second. State compression of BMP route monitor messages within 1 second. State compression of BMP Route Monitoring messages
results in only the final change being transmitted. The other 4 results in only the final change being transmitted. The other 4
changes are suppressed because they fall within the compression changes are suppressed because they fall within the compression
interval. If no compression was being used, all 5 updates would interval. If no compression was being used, all 5 updates would
have been transmitted. have been transmitted.
</t> </t>
<t> <t>
A BMP receiver should expect that Loc-RIB route monitoring granulari A BMP receiver should expect that the granularity of Loc-RIB Route M
ty onitoring can
can be different by BMP sender implementation. vary depending on the BMP sender implementation.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Route Mirroring</name> <name>Route Mirroring</name>
<t> <t>
<xref target="RFC7854" format="default">Section 4.7 of</xref>, <xref target="RFC7854" sectionFormat="of" section="4.7"/>
defines Route Mirroring for verbatim duplication of messages receiv ed. This defines Route Mirroring for verbatim duplication of messages receiv ed. This
is not applicable to Loc-RIB as PDUs are originated by the router. is not applicable to Loc-RIB as PDUs are originated by the router.
Any received Route Mirroring messages SHOULD be ignored. Any received Route Mirroring messages <bcp14>SHOULD</bcp14> be ignor ed.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Statistics Report</name> <name>Statistics Report</name>
<t> <t>
Not all Stat Types are relevant to Loc-RIB. The Stat Types that Not all Stat Types are relevant to Loc-RIB. The Stat Types that
are relevant are listed below: are relevant are listed below:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
Stat Type = 8: (64-bit Gauge) Number of routes in Loc-RIB. Stat Type = 8: (64-bit Gauge) Number of routes in Loc-RIB.
</li> </li>
<li> <li>
Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. The Stat Type = 10: Number of routes in per-AFI/SAFI Loc-RIB. The
value is structured as: 2-byte AFI, 1-byte SAFI, followed by a 64- value is structured as: 2-byte AFI, 1-byte SAFI, followed by a 64-bit Gau
bit Gauge. ge.
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Other Considerations</name> <name>Other Considerations</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Loc-RIB Implementation</name> <name>Loc-RIB Implementation</name>
<t> <t>
There are several methods for a BGP speaker to implement Loc-RIB eff iciently. There are several methods for a BGP speaker to implement Loc-RIB eff iciently.
In all methods, the implementation emulates a peer with Peer Up and Down In all methods, the implementation emulates a peer with Peer Up and Down
messages to convey capabilities as well as Route Monitor messages to messages to convey capabilities as well as Route Monitor messages to
convey Loc-RIB. In this sense, the peer that conveys the Loc-RIB is convey Loc-RIB. In this sense, the peer that conveys the Loc-RIB is
a locally emulated peer. a locally emulated peer.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Multiple Loc-RIB Peers</name> <name>Multiple Loc-RIB Peers</name>
<t> <t>
There MUST be at least one emulated peer for each Loc-RIB instance, There <bcp14>MUST</bcp14> be at least one emulated peer for each Loc -RIB instance,
such as with VRFs. The BMP receiver identifies the Loc-RIB by the pe er such as with VRFs. The BMP receiver identifies the Loc-RIB by the pe er
header distinguisher and BGP ID. The BMP receiver uses the VRF/Tabl e header distinguisher and BGP ID. The BMP receiver uses the VRF/Tabl e
Name from the Peer Up information to associate a name to the Loc-RIB . Name from the Peer Up information to associate a name with the Loc-R IB.
</t> </t>
<t> <t>
In some implementations, it might be required to have more than one In some implementations, it might be required to have more than one
emulated peer for Loc-RIB to convey different address families for emulated peer for Loc-RIB to convey different address families for
the same Loc-RIB. In this case, the peer distinguisher and BGP ID the same Loc-RIB. In this case, the peer distinguisher and BGP ID
should be the same since they represent the same Loc-RIB instance. should be the same since they represent the same Loc-RIB instance.
Each emulated peer instance MUST send a Peer Up with the OPEN messag Each emulated peer instance <bcp14>MUST</bcp14> send a Peer Up with
e the OPEN message
indicating the address family capabilities. A BMP receiver MUST indicating the address family capabilities. A BMP receiver <bcp14>M
UST</bcp14>
process these capabilities to know which peer belongs to which process these capabilities to know which peer belongs to which
address family. address family.
</t> </t>
</section> </section>
<section anchor="FilterLocRib" numbered="true" toc="default"> <section anchor="FilterLocRib" numbered="true" toc="default">
<name>Filtering Loc-RIB to BMP Receivers</name> <name>Filtering Loc-RIB to BMP Receivers</name>
<t> <t>
There maybe be use-cases where BMP receivers should only receive There may be use cases where BMP receivers should only receive
specific routes from Loc-RIB. For example, IPv4 unicast routes may specific routes from Loc-RIB. For example, IPv4 unicast routes may
include internal BGP (IBGP), external BGP (EBGP), and IGP but only include internal BGP (IBGP), external BGP (EBGP), and IGP, but only
routes from EBGP should be sent routes from EBGP should be sent
to the BMP receiver. Alternatively, it may be that only IBGP and to the BMP receiver. Alternatively, it may be that only IBGP and
EBGP that should be sent and IGP redistributed routes should be EBGP should be sent and IGP redistributed routes excluded. In these
excluded. In these cases where the Loc-RIB is filtered, the F flag cases where the Loc-RIB is filtered, the F flag
is set to 1 to indicate to the BMP receiver that the Loc-RIB is is set to 1 to indicate to the BMP receiver that the Loc-RIB is
filtered. If multiple filters are associated to the same Loc-RIB, filtered. If multiple filters are associated with the same Loc-RIB,
a Table Name MUST be used in order to allow a BMP receive a table name <bcp14>MUST</bcp14> be used in order to allo
r to make w a BMP receiver to make
the right associations. the right associations.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Changes to existing BMP sessions</name>
<!-- start here -->
<name>Changes to Existing BMP Sessions</name>
<t> <t>
In case of any change that results in the alteration of b ehavior of In case of any change that results in the alteration of b ehavior of
an existing BMP session, ie. changes to filtering and tab an existing BMP session, i.e., changes to filtering and t
le names, the able names, the
session MUST be bounced with a Peer Down/Peer Up sequence session <bcp14>MUST</bcp14> be bounced with a Peer Down /
. Peer Up sequence.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
The same considerations as in <xref target="RFC7854" format="default">se The same considerations as in <xref target="RFC7854" sectionFormat="of"
ction 11 of</xref> apply to this section="11"/> apply to this
document. Implementations of this protocol SHOULD require that sessions document. Implementations of this protocol <bcp14>SHOULD</bcp14> require
are only established with that sessions only be established with
authorized and trusted monitoring devices. It is also believed that this document does authorized and trusted monitoring devices. It is also believed that this document does
not add any additional security considerations. not introduce any additional security considerations.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t> <t>
This document requests that IANA assign the following new parameters IANA has assigned new parameters
to the <eref target="https://www.iana.org/assignments/bmp-parameters/bmp to the <eref target="https://www.iana.org/assignments/bmp-parameters/">
-parameters.xhtml"> "BGP Monitoring Protocol (BMP) Parameters" registry</eref>.
BMP parameters name space</eref>.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>BMP Peer Type</name> <name>BMP Peer Type</name>
<t> <t>IANA has registered the following new peer type (<xref target="PeerTy
This document defines a new peer type (<xref target="PeerType" forma pe" format="default"/>):
t="default"/>):
</t> </t>
<ul spacing="normal"> <table anchor="t1">
<li> <name>BMP Peer Type</name>
Peer Type = 3: Loc-RIB Instance Peer <thead>
</li> <tr>
</ul> <th>Peer Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>3</td>
<td>Loc-RIB Instance Peer</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>BMP Loc-RIB Instance Peer Flags</name> <name>BMP Loc-RIB Instance Peer Flags</name>
<t> <t>
This document requests IANA to rename "BMP Peer Flags" to IANA has renamed "BMP Peer Flags" to
"BMP Peer Flags for Peer Types 0 through 2" and create a new registr "BMP Peer Flags for Peer Types 0 through 2" and created a new regist
y ry
named "BMP Peer Flags for Loc-RIB Instance Peer Type 3" named "BMP Peer Flags for Loc-RIB Instance Peer Type 3".</t>
This document defines that peer flags are specific to the Loc-RIB in
stance peer type.
As defined in (<xref target="PeerFlags" format="default"/>):
</t> <t>This document defines peer flags that are specific to the
<ul spacing="normal"> Loc-RIB Instance Peer Type. IANA has registered the following in
<li> the "BMP Peer Flags for Loc-RIB Instance Peer Type 3" registry:</t>
Flag 0: The F flag indicates that the Loc-RIB is filtered. This ind <table anchor="t2">
icates <name>Loc-RIB Instance Peer Type</name>
that the Loc-RIB does not represent the complete routing table. <thead>
</li> <tr>
</ul> <th>Flag</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>F flag</td>
</tr>
</tbody>
</table>
<t>As noted in <xref target="PeerFlags"/>, the F flag indicates that the Loc-RIB is filtered. This indicates that the Loc-RIB does not represent the complete r outing table.</t>
<t> <t>
Flags 0 through 3 and 5 through 7 are unassigned. The registration pro Flags 1 through 7 are unassigned. The registration procedure for the
cedure for the registry is Standards Action.
registry is "Standards Action".
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Peer Up Information TLV</name> <name>Peer Up Information TLV</name>
<t> <t>
This document requests that IANA rename IANA has renamed the "BMP Initiation Message TLVs" registry to "BMP
"BMP Initiation Message TLVs" registry to "BMP Initiation and Peer U Initiation and Peer Up Information TLVs".
p Information TLVs." <xref target="RFC7854" sectionFormat="of" section="4.4"/> indicates
<xref target="RFC7854" format="default">section 4.4 of</xref> define that
s that
both Initiation and Peer Up share the same information TLVs. both Initiation and Peer Up share the same information TLVs.
This document defines the following new BMP Peer Up information This document defines the following new BMP Peer Up Information
TLV type (<xref target="PeerUpInfoTlv" format="default"/>): TLV type (<xref target="PeerUpInfoTlv" format="default"/>):</t>
<table anchor="t3">
<name>BMP Peer Up Information TLV Type</name>
<thead>
<tr>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>3</td>
<td>VRF/Table Name</td>
</tr>
</tbody>
</table>
</t> <t>The Information field contains a UTF-8 string whose value
<ul spacing="normal"> <bcp14>MUST</bcp14> be equal to the value of the VRF or table name
<li> (e.g., RD instance name) being conveyed. The string size
Type = 3: VRF/Table Name. <bcp14>MUST</bcp14> be within the range of 1 to 255 bytes.</t>
The Information field contains a UTF-8 string whose value MUST be eq
ual to the
value of the VRF or table name (e.g., RD instance name) being convey
ed.
The string size MUST be within the range of 1 to 255 bytes.
</li>
</ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Peer Down Reason code</name> <name>Peer Down Reason Code</name>
<t> <t>
This document defines the following new BMP Peer Down reason code (< IANA has registered the following new BMP Peer Down reason code
xref target="PeerDownReasonCode" format="default"/>): (<xref target="PeerDownReasonCode" format="default"/>):</t>
<table anchor="t4">
<name>BMP Peer Down Reason Code</name>
<thead>
<tr>
<th>Type</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>6</td>
<td>Local system closed, TLV data follows</td>
</tr>
</tbody>
</table>
</t> </section>
<ul spacing="normal">
<li> <section numbered="true" toc="default">
Type = 6: Local system closed, TLV data follows. <name>Deprecated Entries</name>
</li> <t>Per this document, IANA has marked the F Flag entry in the "BMP
</ul> Peer Flags for Peer Types 0 through 2" registry as
"deprecated".</t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
&RFC2119; <name>References</name>
&RFC8174; <references>
&RFC4271; <name>Normative References</name>
&RFC5226;
&RFC7854; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
</references> xml"/>
<references title="Informative References"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
&rfc7911; xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7854.
xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7911.
xml"/>
</references> </references>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default"> <section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name> <name>Acknowledgements</name>
<t> <t>
The authors would like to thank John Scudder, Jeff Haas and Mukul Srivas tava The authors would like to thank <contact fullname="John Scudder"/>, <con tact fullname="Jeff Haas"/>, and <contact fullname="Mukul Srivastava"/>
for their valuable input. for their valuable input.
</t> </t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 106 change blocks. 
376 lines changed or deleted 460 lines changed or added

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