BMP YANG ModuleNTT164-168, Carrer de NumanciaBarcelona08029Spaincamilo@ntt.netNTTSiriusdreef 70-72HoofddorpWT2132Netherlandspaolo@ntt.netSwisscomBinzring 17Zurich 8045Switzerlandthomas.graf@swisscom.comHuaweibenoit.claise@huawei.com
OPS
GROW
This document proposes a YANG module for BMP (BGP Monitoring Protocol) configuration and monitoring.
A complementary RPC triggers a refresh of the session of a BMP station.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
Routing Information Bases, peers, monitoring stations are defined in .
This document specifies a YANG module for configuring and
monitoring the BGP Monitoring Protocol (BMP) . The model
provides parameters for defining BMP monitoring stations, the
selection of the BGP Routing Information Bases (RIBs), provides
operational metrics and enables to reset BMP monitoring sessions.
The BMP YANG model provides the methods for managing BMP monitoring stations. It includes:
Connectivity parameters, including station IP address and destination port.
BMP session parameters, such as defining the BMP initiation message
or the interval for statistics messages.
BGP Data sources. The model requires the explicit configuration
of the RIBs and address family to send to each monitoring
station. For Adj-RIB-in and Adj-RIB-out, both post and pre policy,
the model also requires the peers from which to originate
data. In those RIBs, the value "all_peers" can be used if the
operators desires to receive data of all peers.
Per BMP station status and statistics, such as established status, number
of route-monitoring messages, number of route-mirroring messages, number
of peer-down and peer-up messages, number of initiation messages.
BMP session reset RPC action.
The following tree diagram provides an overview of the ietf-bmp.yang
data model.
/bmp/stations/station/id
+--ro output
+--ro (outcome)?
+--:(success)
| +--ro success? empty
+--:(failure)
+--ro failure? string
]]><CODE BEGINS> file "ietf-bmp@2022-01-27.yang"
WG List:
Author: Camilo Cardona
Author: Paolo Lucente
Author: Thomas Graf
Author: Benoit Claise
";
description
"This module specifies a structure for BMP
(BGP Monitoring Protocol) configuration and monitoring.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.
Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 9196
(https://www.rfc-editor.org/info/rfc9196); see the RFC itself
for full legal notices.";
revision 2022-01-27 {
description
"initial version";
reference
"RFC YYYY: BMP YANG Module
RFC-EDITOR: please update YYYY with this RFC ID";
}
typedef bmp-peer-types {
type enumeration {
enum all-peers {
value 10;
description
"Selects all peers.";
}
}
description
"Enum values for peer selection specific for BMP. The
all-peers value is an explicit way of defining that the device
should send the updates from all peers to the station for
a particular RIB/AFI. The module also allows the selection
of individual peers (through its remote-address), or use the
bgp:peer-type to select the type of peers.";
}
grouping bmp-ip-connection {
description
"common elements for defining connectivity
to a bmp station";
leaf destination-address {
type inet:ip-address;
mandatory true;
description
"Destination IP address of station";
}
leaf local-address {
type inet:ip-address;
description
"Local IP address to source connections";
}
leaf destination-port {
type inet:port-number;
description
"Destination port for connections";
}
}
grouping bmp-peer-ribs-filter {
description
"Leaves for configuring RIBs where
origin/destination peers are well defined.";
leaf enabled {
type boolean;
description
"Enables the specified RIB";
}
container address-families {
description
"container for lists of address-families";
list address-family {
key "name";
description
"List of address families.
The name of the address family, as defined
in the BGP model is used for keying.";
leaf name {
type leafref {
path "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bgp:bgp/"
+ "bgp:global/bgp:afi-safis/bgp:afi-safi/bgp:name";
}
description
"Name of the address family";
}
leaf-list peers {
type union {
type leafref {
path "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bgp:bgp/"
+ "bgp:neighbors/bgp:neighbor/bgp:remote-address";
}
type bt:peer-type;
type bmp-peer-types;
}
description
"Peers can be identified by a remote-address,
or by an enum value corresponding to groups of peers.
This way an operator can select all external peers,
all internal peers, or all peers.";
}
}
}
}
grouping bmp-route-monitoring-sources {
description
"";
container adj-rib-in-pre {
description
"Configuration for the adj-rib-in pre-policy";
reference
"RFC7854: BGP Monitoring Protocol (BMP), Section 2.";
uses bmp-peer-ribs-filter;
}
container adj-rib-in-post {
description
"Configuration for the adj-rib-in post-policy";
reference
"RFC7854: BGP Monitoring Protocol (BMP), Section 2.";
uses bmp-peer-ribs-filter;
}
container local-rib {
description
"Configuration for the local-rib";
reference
"RFC9069: Support for Local RIB in the BGP Monitoring
Protocol (BMP), Section 3.";
leaf enabled {
type boolean;
description
"Enables the specified RIB";
}
leaf-list address-families {
type identityref {
base bt:afi-safi-type;
}
description
"List of address families to enable for
local-rib.";
}
}
container adj-rib-out-pre {
description
"Configuration for the adj-rib-out pre-policy";
uses bmp-peer-ribs-filter;
reference
"RFC8671: Support for Adj-RIB-Out in the BGP Monitoring
Protocol (BMP) , Section 3.";
}
container adj-rib-out-post {
description
"Configuration for the adj-rib-out post-policy";
uses bmp-peer-ribs-filter;
reference
"RFC8671: Support for Adj-RIB-Out in the BGP Monitoring
Protocol (BMP) , Section 3.";
}
}
grouping bmp-session-options {
description
"leaves for configuration of the bmp session";
leaf initiation-message {
type string;
description
"User defined message to append to the
initiation message";
}
leaf statistics-interval {
type uint32;
description
"Default Interval for statistic message.";
}
}
container bmp {
description
"Main level for BMP configuration ";
container stations {
description
"Container for the list of BMP stations";
list station {
key "id";
description
"Configuration for BMP stations.";
leaf id {
type string;
description
"Identification string for the station";
}
// Connection, missing tcp tuning params
// like keep-alives, segment sizes, etc.
container connection {
description
"Connection details for the station";
uses bmp-ip-connection;
}
container bmp_session {
description
"BMP session options for the station";
uses bmp-session-options;
}
container bmp_sources {
description
"Configuration of the data sources for the station";
uses bmp-route-monitoring-sources;
}
container session-stats {
description
"stats and operational values for the station";
leaf discontinuity-time {
type yang:date-and-time;
mandatory true;
description
"The time on the most recent occasion at which any one
or more of this station's counters suffered a
discontinuity. If no such discontinuities have
occurred since the last re-initialization of the local
management subsystem, then this node contains the time
the local management subsystem re-initialized
itself.";
}
leaf established-session {
type boolean;
config false;
description
"Value indicating if the session is currently
established";
}
leaf total-route-monitoring-messages {
type uint64;
config false;
description
"Number of route-monitoring messages sent since last
successful connection";
}
leaf total-statistics-messages {
type uint64;
config false;
description
"Number of statistics messages sent since last
successful connection";
}
leaf total-peer-down-messages {
type uint64;
config false;
description
"Number of peer-down messages sent since last
successful connection";
}
leaf total-peer-up-messages {
type uint64;
config false;
description
"Number of peer-up messages sent since last successful
connection";
}
leaf total-initiation-messages {
type uint64;
config false;
description
"Number of initiation messages sent since last
successful connection";
}
leaf total-route-mirroring-messages {
type uint64;
config false;
description
"Number of route-mirroring messages sent since last
successful connection";
}
}
}
}
container actions {
nacm:default-deny-all;
description
"Container with the actions for the BMP operation";
action session-reset {
description
"Resets the session for a station.";
input {
leaf station {
type leafref {
path "/bmp/stations/station/id";
}
description
"Identifies the station to reset";
}
}
output {
choice outcome {
description
"Output of the reset operation. Either a success or
failure. For the latter, the reason for the
error is provided.";
leaf success {
type empty;
description
"Reset successful";
}
leaf failure {
type string;
description
"Reset could not be performed.
Reason is included in the field";
}
}
}
}
}
}
}
]]><CODE ENDS>
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport
layer, and the mandatory-to-implement secure transport is Secure
Shell (SSH) . The lowest RESTCONF layer is
HTTPS, and the mandatory-to-implement secure transport is TLS . The NETCONF Access Control Model (NACM) provides the means to restrict access for
particular NETCONF or RESTCONF users to a preconfigured subset of all
available NETCONF or RESTCONF protocol operations and content.
BGP data is sensible for security considerations. The model described
in this document could be used to send BGP information to malicious
BMP stations. Write access to this model should therefore be
properly protected.
The session-reset action can demand considerable amount of resources
from network elements. It should thus be protected from illegal access.
This document registers a URIs in the IETF XML
registry . Following the format in
, the following registrations are
requested:
URI: urn:ietf:params:xml:ns:yang:ietf-bmp
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
This document registers the following YANG module in the "
YANG Module Names" registry
registry :
Name: ietf-bmp
Namespace: urn:ietf:params:xml:ns:yang:ietf-bmp
Prefix: bmp
Reference: [This RFC-to-be]
Shall we copy the TCP tuning and security parameters from the BGP specifications?The security considerations section will have to be aligned with
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
The authors would like to thank Pierre Vander Vorst and Tom Petch for their review and feedback.