Subject: [GROW] The new BMP drafts and new BMP functionality

From: Henk Smit <[email-masked]>
Date: Mon, 26 Mar 2018 15:13:31 +0200

Hello all,

I've read the 2 new BMP drafts.
I don't like them very much.
I think we can do better.

What the new drafts propose:
----
The new drafts introduce new ways to report routes from the Adj-RIB-Out
and Loc-RIB to bmp-stations.

The Adj-RIB-Out draft does that by using a flag from the BMP per-peer
header's flag-field. This new flag indicates that a reported route is
from the Adj-RIB-Out in stead of the Adj-RIB-In.
I don't like this.

The flags-field has only 8 bits. We were using 3 of them. This draft
uses a 4th. And the Loc-RIB draft introduces yet another flag. We'll
be running out of flags soon.

The Loc-RIB draft introduces a new peer-type, the so-called
"Loc-RIB Instance Peer". Note, we already had a "Local Instance Peer".
I don't find this naming very clear. I also don't like mixing three
different types of routes (In, Out, Loc) in the same message-type.

What I propose:
----
We have 256 message-types. We are using 7 of those now.
I think it would be wiser to introduce a new message-type for
reporting Adj-RIB-Out routes. That is 1) a bit cleaner, and 2) it
allows us to use the flags in the flag-field for more important or
more useful things.

If we are introducing a new message-type for Adj-RIB-Out, we can just
as well introduce a new message type for Loc-RIB routes. That makes
the distinction between the 3 different types of routes a lot cleaner.

What about the old route-monitoring message ?
----
Modern protocols are developed using TLVs.
BMP does have TLVs in some of its messages too (init, term, peer-up, 
etc).
However, the most important message in BMP, the route-monitoring message
is fixed format. I think that is a bug.
The route-monitoring message consists of:
1) the small common BMP header
2) the per-peer header
3) the reported route(s), encapsulated in a BGP update-message.

There is no flexibility here to add more information.
That is a short-coming.
The whole body of the message should be TLV-based.
Therefor I propose we use the following message-format for the
new route-report messages.

1) small common BMP header
2) the per-peer header
3) TLVs, these consist of:
    a) zero or more informational TLVs.
       these can include tags, reason why a route was dropped or 
accepted,
       did this route win best-path computation ? is the route installed 
in
       the GRT/RIB/RTM ? we can add any new information here, in the 
future,
       by just defining a new TLV.
    b) a TLV which holds the BGP update-message.

This format should apply to all 3 new message-types, for Adj-RIB-In,
Adj-RIB-Out and Loc-RIB.

What is the impact of this change ?
----
The BMP protocol remains largely the same.
The common BMP header and the per-peer header stay the same.
The init and termination messages stay the same.
The peer-up and peer-down messages stay the same.
These last 4 messages are already really TLV-based.
Only the route-monitoring messages need to change.

Sending and parsing of the route-monitoring is largely the same
as it is today. The only difference is that a bunch of TLVs can
be sent along with the BGP update message. Existing bmp-station
implementations can be easily altered to accept the 3 new 
route-monitoring
messages, and just skip the TLVs. That's less than a day's work.
If a bmp-station implementation wants to know about the new TLVs, new
code can be written and introduced to parse and process the extra
information on a TLV-by-TLV bases. The BMP protocol is now extensible.

Do we need to bump BMP to version 4 ?
----
It might be nice to do this.
But technically there is no need. Old bmp-station implementations will
accept the 3 new BMP messages, and (hopefully) skip the message-types 
they
don't know about. Routers can have a configuration knob to send only
old-fashioned route-monitoring messages (type 0). Or they could send
routes in the 3 new message-formats. This is straight-forward to 
implement.

Flags in the flags-field in the per-peer header
----
The flags-field in the per-peer header has 8 bits.
Currently we use 3 of those.
V-bit indicates the peer uses an IPv6 address.
L-bit indicates post-policy
A-bit indicates 2-byte as-path

I'd like to use a few more bits.

1) We have a bit to indicate that a route is sent with pre-policy 
attributes
    or with post-policy attributes. If we want to send both, we have to 
send
    2 BMP messages. If the attributes are unaltered, we still have to 
send
    2 messages.
    I'd like to see 2 bits in stead of 1 bit. One for post-policy, and a 
new
    bit for pre-policy. This will allow us to report the same route only 
once
    in stead of twice.

2) It might be nice to have a bit indicating that a post-policy route
    was denied into the BGP-RIB by policy. This could also be done via a
    TLV in the new route-monitoring messages. So maybe we shouldn't use a 
bit
    for this.

3) This is a personal one. When parsing a BGP update-message in a BMP
    route-monitoring message, you need to know if the prefix has a 
path-id
    in front of it or not. The only way to know this is by looking at the
    OPEN messages in the BMP peer-up messages. This is fine for elaborate
    bmp-station implementations like OpenBMP. But for state-less software
    that looks at BMP messages, it is impossible to parse route-mon 
messages.
    This is a problem for sniffers like WireShark or tcpdump. E.g. the 
peer-up
    message might have been sent hours or days ago. Also developing 
simple
    tools for testing or trouble-shooting or development is a pain when
    add-paths is configured.
    Therefor I'd like to dedicate one bit in the flags-field to indicate
    that the NLRI inside the bgp-updates messages have a path-id.
    We have a similar bit to distinguish between 2-byte and 4-byte ASNs. 
Having
    a bit to indicate add-paths is kinda the same.

My apologies for the long email.
Thanks for your attention,

henk.

====
About myself (because this is the first email I'm sending to the IETF in 
20 years).
----
I work for a router-vendor.
At the IETF I represent myself, not my employer.
Lately I've been working on a BMP implementation.
Router-side, where BGP in a router sends BMP-messages to bmp-stations.
(For those who recognize my employer's version numbering:
  our BMP will be released 1-2 months from now, in release 16.0R1).