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.

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.

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. Limitations of the current route-monitoring message format
• 3. Proposed changes
• 4. New Message-types
• 5. TLV-encoding
• 6. BGP Update Message TLV
• 7. Flags-field TLV
• 7.1. Two flags per piece of state
• 7.2. Proposed flags in the flag-field TLV
• 7.3. Reporting state in the flags-field TLV that is already known
• 8. Example of layout of a tlv-encoded BMP route-monitoring message
• 9. Security Considerations
• 10. Acknowledgements
• 11. Contributor Addresses
• 12. IANA Considerations
• 13. References
• 13.1. Normative References
• 13.2. Informative References
• Author's Address

1. Introduction

The BGP Monitoring Protocol (BMP) is defined in RFC 7854. One of the message-types is the Route-Monitoring message. The route-monitoring message consists of:

• generic bmp header
• per-peer bmp header
• 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). A second draft proposes how to report routes that are in BGP's own RIB (Loc-RIB). 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
• 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.

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:

• 2 octets of TLV-type,
• 2 octets of TLV-length,
• 0 or more octets of TLV value.

	  
  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 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
• 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:

• generic bmp header, 6 bytes
• per-peer bmp header, 42 bytes
• tlv-header, type = BGP update message TLV
• tlv-content: bgp update message, including bgp header and marker
• tvl-header, type = Flags-field TLV, length is 2
• tlv-content: 16 bits of flags
• potentially more TLVs, to be defined in future drafts

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

13.2. Informative References

Author's Address