BMP Compression
draft-msri-grow-bmp-compression-00

Document Type Active Internet-Draft (individual)
Last updated 2019-10-15
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      M. Srivastava
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                              P. Lucente
Expires: April 17, 2020                                              NTT
                                                        October 15, 2019

                            BMP Compression
                   draft-msri-grow-bmp-compression-00

Abstract

   This document provides specification for an optional compressed BMP
   Feed from a router to BMP station.

Requirements Language

   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 [RFC2119] RFC 8174 [RFC8174] when, and only when, they
   appear in all capitals, as shown here.

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 April 17, 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

Srivastava & Lucente     Expires April 17, 2020                 [Page 1]
Internet-Draft               BMP compression                October 2019

   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.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Starting Compressor Capability  . . . . . . . . . . . . .   3
     2.2.  Compression Information TLV . . . . . . . . . . . . . . .   3
     2.3.  Compressed BMP Messages . . . . . . . . . . . . . . . . .   4
     2.4.  Compressor Overflow . . . . . . . . . . . . . . . . . . .   4
     2.5.  Error Handling  . . . . . . . . . . . . . . . . . . . . .   4
     2.6.  Processing of Compressed Route Monitoring messages  . . .   5
   3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  BMP Compression Information TLV . . . . . . . . . . . . .   5
     4.2.  BMP Compression Route Monitoring message type . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The BGP Monitoring Protocol (BMP) allows monitoring of Rib-in RFC7854
   [RFC7854], Loc-Rib,BGP local-rib [I-D.ietf-grow-bmp-local-rib] and
   Rib-in and Rib-Out monitoring allows pre-policy and post-policy view
   of the prefix.  Thus, for a scaled setup, with all these kinds of
   monitoring enabled, BMP will get a lot of back pressure in the
   protocol as it needs to dump a huge data for its monitored peers,
   through a single socket towards BMP station.  BGP update PDU which is
   part of the BMP Route-monitoring (RM) message is also increasing.  It
   is no more limited to 4K as noted in draft-ietf-idr-bgp-extended-
   messages-21.  Essentially, BMP is heading towards becoming I/O bound
   monitoring protocol.  This document proposes compression of BMP feed
   towards BMP station.  Compression will ease the pressure on TCP
   socket between a router and BMP station.  Such a scheme would be
   useful if a route can spare some extra CPU for BMP operation.

   As it must be obvious, this scheme will require compressor mechanism
   at the BMP speaking router and a decompressor on the BMP station.
   The compression mechanism used at the BMP speaking is an
   implementation specific detail and is beyond the scope of this
   specification.

Srivastava & Lucente     Expires April 17, 2020                 [Page 2]
Internet-Draft               BMP compression                October 2019

2.  Procedures

2.1.  Starting Compressor Capability

   BMP compression feature on the router and BMP decompressor feature on
   the BMP station has to be present at the same time.  Enabling
   compression feature at router end only will lead to incomprehensible
   data at the BMP station end.  Also same technique should be used to
   compress and decompress the data on wire.  Using different technique
   to compress and decompress would lead to incomprehensible data at the
   BMP station end.

   BMP compression feature on the router and BMP decompressor feature on
   the BMP station can be enabled via configuraton.  Once this feature
   is enabled between router and BMP station, the monitored router
   should indicate this to the BMP Station using new Compression
   Information TLV as described in following section.

   From that point onwards, the router would send the compressed BMP
   feed towards BMP station.  BMP session needs to be bounced every-time
   this feature is enabled on a current active BMP session.

2.2.  Compression Information TLV

   As noted in RFC7854 [RFC7854], the initiation message provides a
   means for the monitored router to inform the monitoring station of
   its vendor specific details.  It can carry Information TLVs
   containing information about the monitored router.

   The monitored router MUST communicate the compression capability to
   BMP staton using Compression Information TLV described below.

      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
     +-------------------------------+-------------------------------+
     | Information Type (2 octets)   |     Length (2 octets)         |
     +-------------------------------+-------------------------------+
     | CM | CMINFO |                Reserved                         |
     +---------------------------------------------------------------+

                       Figure 1: Compression Information TLV

   o  Type = TDB1 (2 Octets): Compression Information TLV type.

   o  Length (2 Octets): indicates the length of the value field of the
      Compression Information TLV.  The value field further consists of
      the Compression string.

Srivastava & Lucente     Expires April 17, 2020                 [Page 3]
Internet-Draft               BMP compression                October 2019

   o  CM (4 bits): CM indicating DEFLATE compressed format value as
      specified in RFC1950.

   o  CINFO (4 bits): INFO as specified in RFC1950.  Invalid values MUST
      lead to the capability being ignored.  The compressing peer MUST
      use this value for the parametrization of its algorithm.

2.3.  Compressed BMP Messages

   Following rules should be following for achieving BMP feed
   compression:

   1.  A new message type, Compressed Route Monitoring (CRM), MUST be
       used.  This is to ensure backward compatibility with BMP stations
       that do not support the compression capability.  The message type
       is same in structure as described by TLV support for BMP Route
       Monitoring and Peer Down Messages [I-D.ietf-grow-bmp-tlv].
       Compression is to be applied only to this message type, all other
       BMP message types shall not be compressed.

   2.  Compression is applicable to all the payload following the Common
       Header, described in Section 4.1 of [RFC7854].  This allows to
       read the total BMP message length, i.e. to perform sanity checks
       against socket and compressor information.

   3.  Each compressed BMP message MUST be sent as a block, i.e. the
       decompression MUST be able to yield decompressed results of the
       without waiting for further compressed updates.  This is
       different from the normally used stream compression mode.

   4.  The compressed message MAY exceed the maximum message size but in
       such case compressor overflow per Section 2.4 MUST be invoked.

2.4.  Compressor Overflow

   This should be handled in same was as described in draft-przygienda-
   idr-compressed-updates [I-D.przygienda-idr-compressed-updates].

2.5.  Error Handling

   If the decompression on the BMP station fails for any reason, it
   needs to bring down the BMP session.

   If the compression on the monitoring router fails for any reason, it
   is at the discretion of the router to handle it.  It may try it few
   more times.  In the worse case it MAY bring down the BMP session

Srivastava & Lucente     Expires April 17, 2020                 [Page 4]
Internet-Draft               BMP compression                October 2019

2.6.  Processing of Compressed Route Monitoring messages

   A BMP station receiving a compressed message SHOULD process it as
   follows:

   1.  Decode the BMP Common Header where message length is specified

   2.  Decompress remainder of the Compressed Route Monitoring message
       and determine the decompressed message size from the decompressor

   3.  Decode the BMP Per-peer header

   4.  Decode the BGP UPDATE PDU header to infer the presence of
       trailing TLVs

   5.  Decode the BMP message TLVs

   6.  Decode the actual BGP UPDATE PDU

3.  Acknowledgements

   TBD.

4.  IANA Considerations

   This document requests that IANA assign the following new parameters
   to the BMP parameters name space.

4.1.  BMP Compression Information TLV

   This document defines the BMP Compression Information TLV Header with
   Type = TBD (Section 2.2).

4.2.  BMP Compression Route Monitoring message type

   This document also defines the BMP Compressed Route Monitoring
   message type with Type = TBD (Section 2.3).

5.  Security Considerations

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

6.  Normative References

Srivastava & Lucente     Expires April 17, 2020                 [Page 5]
Internet-Draft               BMP compression                October 2019

   [I-D.ietf-grow-bmp-local-rib]
              Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente,
              "Support for Local RIB in BGP Monitoring Protocol (BMP)",
              draft-ietf-grow-bmp-local-rib-05 (work in progress),
              August 2019.

   [I-D.ietf-grow-bmp-tlv]
              Lucente, P., Gu, Y., and H. Smit, "TLV support for BMP
              Route Monitoring and Peer Down Messages", draft-ietf-grow-
              bmp-tlv-01 (work in progress), October 2019.

   [I-D.przygienda-idr-compressed-updates]
              Przygienda, T., Lingala, A., Mate, C., and J. Tantsura,
              "Compressed BGP Update Message", draft-przygienda-idr-
              compressed-updates-07 (work in progress), August 2019.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7854]  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>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Mukul Srivastava
   Juniper Networks
   10 Technology Park Drive
   Westford MA  01886
   USA

   Email: msri@juniper.net

   Paolo Lucente
   NTT
   Siriusdreef 70-72
   Hoofddorp, WT  2132
   Netherlands

   Email: paolo@ntt.net

Srivastava & Lucente     Expires April 17, 2020                 [Page 6]