Storing BMP messages in MRT Format
draft-petrie-grow-mrt-bmp-00

Abstract

This document extends the Multi-threaded Routing Toolkit (MRT) export format to support the storage of BMP messages.

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 May 4, 2020.

Copyright Notice

Copyright (c) 2019 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. BMP Type
• 3. IANA Considerations
• 4. Security Considerations
• 5. Normative References
• Author's Address

1. Introduction

The MRT record format was developed to provide researchers and engineers a means to encapsulate, export, and archive routing protocol transactions and routing information base snapshots.

BMP was developed to monitor BGP sessions, and also includes messages containing routing protocol transactions and Routing Information Base contents and changes. BMP does not define a mechanism for exporting and archiving BMP messages. MRT can be a suitable format for this.

This document contains an optional extension to the MRT format [RFC6396] and defines additional MRT types to permit storage of BMP messages.

2. BMP Type

This document defines the following new MRT Types:

• BMP
• BMP_ET

These MRT types support the BMP protocol. They are used to encode the exchange of BMP messages. The _ET variant is for use with the Extended Timestamp MRT Header.

The format of the MRT Message field for the BMP types is as follows:

                    
 0                   1                   2                   3
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Address Family           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Remote IP Address (variable)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Local IP Address (variable)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  BMP Message Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    
		

Figure 1

The Address Family indicates what types of addresses are in the subsequent address fields. At present, the following AFI Types are supported:

• 1 - AFI_IPv4
• 2 - AFI_IPv6

The Address Family value only applies to the IP addresses contained in the MRT header. The BMP type is otherwise transparent to the contents of the actual message that may contain any valid AFI/SAFI values.

Remote and Local IP addresses refer to the endpoints of the TCP connection carrying the BMP session, from the perspective of the BMP monitoring station that is recording these messages

3. IANA Considerations

This document requests that IANA assign Type codes to the MRT name space:

• BMP = TBD1 (Section 2)
• BMP_ET = TBD2 (Section 2)

In this draft document this is requested from the Specification Required range, this may be changed to the IETF Review range by a later version of this document.

4. Security Considerations

It is not believed that this document adds any additional security considerations.

However, the security considerations of [RFC6396] and [RFC7854] are equally applicable to this document.

5. Normative References

Author's Address