[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/