Internet DRAFT - draft-hsmit-bmp-extensible-routemon-msgs
draft-hsmit-bmp-extensible-routemon-msgs
GROW Working Group H. Smit, Ed.
Internet-Draft Nokia
Intended status: Standards Track July 18, 2018
Expires: January 19, 2019
BMP Extensible Route-Monitoring Messages
draft-hsmit-bmp-extensible-routemon-msgs-00
Abstract
The BGP Monitoring Protocol (BMP) is defined in RFC7854. Most of the
types of messages in BMP are extensible via the mechanism of TLVs.
However, the most important type of message, the route-monitoring
message, has a fixed format.
This document proposes a relatively small change to the format of BMP
route-monitoring messages. The new format of route-monitoring
messages is no longer fixed-format, but tlv-encoded. This document
also proposes to split the route-monitoring message-type into 3 new
message-types. For Adj-RIB-In, Adj-RIB-Out and Loc-RIB.
This document proposes two types of TLVs to be used in this new
format. A TLV to report the BGP update message itself. And a flags-
field TLV, to report state of the reported routes.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 19, 2019.
Smit Expires January 19, 2019 [Page 1]
Internet-Draft BMP Extensible Route-Monitoring Messages July 2018
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Limitations of the current route-monitoring message format . 3
3. Proposed changes . . . . . . . . . . . . . . . . . . . . . . 4
4. New Message-types . . . . . . . . . . . . . . . . . . . . . . 5
5. TLV-encoding . . . . . . . . . . . . . . . . . . . . . . . . 5
6. BGP Update Message TLV . . . . . . . . . . . . . . . . . . . 6
7. Flags-field TLV . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Two flags per piece of state . . . . . . . . . . . . . . 6
7.2. Proposed flags in the flag-field TLV . . . . . . . . . . 7
7.3. Reporting state in the flags-field TLV that is already
known . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Example of layout of a tlv-encoded BMP route-monitoring
message . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
11. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 9
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
13.1. Normative References . . . . . . . . . . . . . . . . . . 9
13.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
The BGP Monitoring Protocol (BMP) is defined in RFC 7854 [2]. One of
the message-types is the Route-Monitoring message. The route-
monitoring message consists of:
o generic bmp header
o per-peer bmp header
Smit Expires January 19, 2019 [Page 2]
Internet-Draft BMP Extensible Route-Monitoring Messages July 2018
o a full BGP update message
This means that route-monitoring messages have a fixed format. This
brings some limitations to the BMP protocol regarding extensibility.
Many protocols use a tlv-encoding for the format of their messages.
IS-IS is a prime example. But also BGP itself uses a form of tlv-
encoding, namely when encoding path-attributes.
BMP also uses TLVs, but not for all message. Initiation,
termination, peer-up and peer-down messages all use tlv-encoding.
Stats-messages consists of counters, where those counters are tlv-
encoded. But the route-monitoring messages are not tlv-encoded.
This document proposes a new format for BMP Adj-RIB-In route-
monitoring messages, which uses tlv-encoding.
There are currently two other proposals to enhance BMP. The original
BMP specification in RFC7854 defines how a router can report incoming
BGP routes (Adj-RIB-In) to a BMP collector. One draft describes a
new proposal how to report outgoing routes (Adj-RIB-Out) [4]. A
second draft proposes how to report routes that are in BGP's own RIB
(Loc-RIB) [3]. This document proposes to use 2 more new message-
types to report these Adj-RIB-Out and Loc-RIB routes.
This document does not propose any changes to BMP messages other than
route-monitoring messages.
2. Limitations of the current route-monitoring message format
There are a few short-comings with the current format of Route-
Monitoring messages. These short-comings also apply to the new
formats proposed in the Adj-RIB-Out and Loc-RIB drafts.
1) The format of route-monitoring message is fixed. This prevents
us from adding more information to each reported route. This
extra information can be simple state in the form of a simple bit.
Examples of this are whether a route:
* route has passed a policy or filter or not,
* route has won BGP's best path selection for that NLRI or not
* route is installed in the global routing table or not
* route has a valid next-hop or not
Smit Expires January 19, 2019 [Page 3]
Internet-Draft BMP Extensible Route-Monitoring Messages July 2018
More elaborate state can also be reported together with the route
itself. E.g.:
* if a route was rejected because of a policy or filter, BMP
could report why the route was rejected. E.g. it could report
the policy's name or identifier, and the line-number or entry-
number that caused the route to be rejected.
* if a route did not win best-path selection, BMP could report
why it didn't win. E.g. this route had a longer as-path, a
lower local-preference, or it lost because the IGP cost to the
next-hop is higher.
2) Some state of a route is reported in BMP's per-peer header.
One would expect that the per-peer header would hold state about
the peer itself. E.g. whether the peer's ip-address is IPv4 or
IPv6. Not how a BGP update-message is encoded (with 4-byte ASNs)
or whether the attributes of a route are pre-policy or post-
policy. But the real limitation is that the per-peer header has
only 8 bits in its flags-field. There is only a limited amount of
state we can store in those 8 bits. And half of them are used up
already.
3) The route-monitoring message is overloaded. We use it for
routes from the Adj-RIB-In, Adj-RIB-Out and Loc-RIB. E.g. to
determine that a route-monitoring message holds a route in the
Loc-RIB, the peer-type in the per-peer header is set to a special
value (TBD), and a number of fields are set blank. This means
that the BMP collector now knows which route is in the BGP-Loc-
RIB, but it still doesn't know where that route came from.
Putting all three different types of routes in the same message-
type will make it harder to deal with them, when these types of
routes require different treatment.
3. Proposed changes
1) Define a new tlv-based encoding for route-monitoring messages.
This means that the encoding is not backwards compatible with the old
fixed-format encoding. Therefor we need to define a new message-
type.
2) When we are defining a new message-type for Adj-RIB-In messages,
we can just as well define 3 different message-types: one for Adj-
RIB-In messages, one for Adj-RIB-Out messages, and one for Loc-RIB
messages.
Smit Expires January 19, 2019 [Page 4]
Internet-Draft BMP Extensible Route-Monitoring Messages July 2018
3) There must be a TLV that holds the original content of a route-
monitoring message: namely the original BGP update message itself.
4) This document proposes another new TLV, namely the flags-field
TLV. The flags-field TLV consists of a variable number of bits,
where each bit represents some state of that route. The flags-field
TLV is variable in length. Therefor we can add state in the future,
almost indefinitely.
4. New Message-types
We need 3 new message-types. For Adj-RIB-In, Adj-RIB-Out and Loc-RIB
routes. The old route-monitoring message (type 0) can be deprecated
over time. The new values are TBD. But obvious values would be 7
(Adj-RIB-In), 8 (Adj-RIB-Out) and 9 (Loc-RIB).
In the mean time, BMP collectors can accept all 4 message-types.
When they receive an old route-monitoring message, they know the
content consists of just a BGP update message. So they can parse the
message. When a BMP collector receives one of the new 3 message-
types, they know the message body consists of TLVs, and they can
parse those. Therefor BMP collectors do not require any
configuration to deal with routers that do and do not support the new
tlv-encoding. Routers will need a configuration options, so that
providers can configure their routers to send only type 0 route-
monitoring messages to old collectors that do not understand the tlv-
encoding (yet).
5. TLV-encoding
The Adj-RIB-In, Adj-RIB-Out and Loc-RIB route-monitoring messages use
tlv-encoding as defined in RFC7854. This means that the body of the
route-monitoring message consists of one or more TLVs. A TLV
consists of:
o 2 octets of TLV-type,
o 2 octets of TLV-length,
o 0 or more octets of TLV value.
Smit Expires January 19, 2019 [Page 5]
Internet-Draft BMP Extensible Route-Monitoring Messages July 2018
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (2 octets) | Length (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable, between, 0 and 65535 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
TLVs in the body of a route-monitoring message MAY be sent in any
order. At least one TLV MUST be present in the body of the message.
Preferably the BGP update message TLV. Sending a flags-field TLV is
highly recommended (SHOULD).
6. BGP Update Message TLV
TLV-type is TBD. Suggest value is 1.
The content of the BGP update message TLV is simply a full BGP update
message. The content of this TLV should be the same as when a router
would send the BGP update message in the old non-tlv-encoded format,
as in route-monitoring messages of type 0. The length of the BGP
message in the BGP header should be the same as the length of the TLV
in the TLV-length field.
7. Flags-field TLV
TLV-type is TBD. Suggested value is 2.
The length of this TLV is 0 more bytes. A BMP collector MUST be
prepared to receive a flags-field TLV with any length. When a BMP
collector receives more bits in the flags-field TLV than it knows the
definition of, it can ignore the additional bits.
The flags-field TLV is used in both Adj-RIB-In, Adj-RIB-Out and Loc-
RIB messages. The flags keep their meaning between message-types.
If a flag does not have any practical meaning for the message-type,
it should be ignored. An example of this are the pre-policy and
post-policy flags for the Loc-RIB routes.
7.1. Two flags per piece of state
For most state, the flags-field TLV has 2 bits. One bit to state if
something is true, and another bit to state that something is not
true. E.g. there are 2 flags to state that a route has won the BGP
best-path selection. The reason for this is that when we have 2
Smit Expires January 19, 2019 [Page 6]
Internet-Draft BMP Extensible Route-Monitoring Messages July 2018
bits, a router can report a state when it knows that state. Or it
can decide to not report that state. E.g. because it doesn't know
the state (yet). Suppose a router reports an Adj-RIB-In route after
it received that route, but before it has ran best-path computation.
The 2 flags for best-route can be set to 0. Later, after BGP has run
best-path computation for that NLRI, the router can report a Loc-RIB
message to the collector, and set one of the two flags indicating
whether a route won best-path or not.
Having 2 bits per state has the advantage that not all routers are
required to support all flags. Unsupported state can always be set
to zero. It also allows a router to send all state in a single
message, if it can do that. E.g. when a router reports Adj-RIB-In
routes after it has run best-path computation and after the BGP route
was installed in the global routing table, BMP can report all that
state in a single message.
7.2. Proposed flags in the flag-field TLV
1) path-attributes are pre-policy
2) path-attributes are post-policy
3) route is valid
4) route in invalid (e.g. next-hop is unreachable)
5) route is accepted by policy
6) route is rejected by policy
7) route is best BGP route after best-path selection
8) route is not best BGP route after best-path selection
9) route is installed in global (or VRF's) routing table
10) route is not installed in global routing table
11) as-path is in 4-byte ASN notation
12) unused
13) NLRI have path-id (add-paths)
14) NLRI do not have path-id (add-paths)
15) route in global routing table is used/best
Smit Expires January 19, 2019 [Page 7]
Internet-Draft BMP Extensible Route-Monitoring Messages July 2018
16) route in global routing table is not used/not best
The exact meaning of each flag needs further discussion. More flags
can be added to this document, if necessary. Or added later, as part
of future extensions of the BMP protocol.
7.3. Reporting state in the flags-field TLV that is already known
This document proposes some flags in the flags-field TLV that are not
absolutely necessary. E.g. there are 2 flags to indicate whether
NLRI in the BGP update message are encoding with a path-id (add-
paths).
A BMP collector can know this already, when it has kept state from
the BGP OPEN messages in the BMP peer-up messages. However, this can
have practical limitations. Parsing a BMP message now requires
state. It would be nice if BMP messages can be parsed without any
priory state. E.g. this would make sniffing BMP packets with tools
like tcpdump or WireShark a lot easier.
RFC7854 has a single bit to indicate whether a reported route has
pre-policy or post-policy attributes with the route. This document
proposes to use 2 bits. This way a router can report both pre-policy
and post-policy routes in a single BMP message, if the attributes are
unchanged by policy.
8. Example of layout of a tlv-encoded BMP route-monitoring message
A BMP Adj-RIB-In route-monitoring message can look like:
o generic bmp header, 6 bytes
o per-peer bmp header, 42 bytes
o tlv-header, type = BGP update message TLV
o tlv-content: bgp update message, including bgp header and marker
o tvl-header, type = Flags-field TLV, length is 2
o tlv-content: 16 bits of flags
o potentially more TLVs, to be defined in future drafts
Smit Expires January 19, 2019 [Page 8]
Internet-Draft BMP Extensible Route-Monitoring Messages July 2018
9. Security Considerations
This draft has no implications on the security aspect of BMP
10. Acknowledgements
The author would like to express thanks to Alejandro Ayala and Gunter
Van De Velde for their suggestions and comments.
11. Contributor Addresses
Below is a list of other contributing authors in alphabetical order:
Figure 2
12. IANA Considerations
This document requests three new message-types in BMP.
This document creates a new list of TLVs to be used in the three new
route-monitoring messages
This document defines an extensible TLV, called the Flags-field TLV.
New meaning to bits in the Flags-field TLV can be assigned in the
future.
13. References
13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://xml.resource.org/public/rfc/html/rfc2119.html>.
[2] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP
Monitoring Protocol (BMP)", RFC 7854,
DOI 10.17487/RFC7854, June 2016,
<https://www.rfc-editor.org/info/rfc7854>.
13.2. Informative References
[3] Evens, T., Bayraktar, S., and P. Lucente, "Support for
Local RIB in BGP Monitoring Protocol (BMP)", February
2018.
Smit Expires January 19, 2019 [Page 9]
Internet-Draft BMP Extensible Route-Monitoring Messages July 2018
[4] Evens, T., Bayraktar, S., Lucente, P., Mi, P., and S.
Zhuang, "Support for Adj-RIB-Out in BGP Monitoring
Protocol (BMP)", March 2018.
Author's Address
Henk Smit (editor)
Nokia
Antwerp
Belgium
Email: henk_hw.smit@nokia.com
Smit Expires January 19, 2019 [Page 10]
