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).
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
