Hello all,
I've posted a new draft, about BMP.
As I've explained on this list before, I think that if we're adjusting
BMP, we could just as well give the route-monitoring messages a new
format.
Which should use tlv-encoding.
For more information, see the draft here:
https://datatracker.ietf.org/doc/draft-hsmit-bmp-extensible-routemon-msgs/
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.
I have implemented the new encoding in Nokia's SR-OS.
However, this new functionality is not available to our customers (yet).
Let me know if you are interested.
I have made available an example with BMP data in the new format.
Implementors of BMP-collectors can have a look to see what the
new format looks like.
Get it here:
http://hhwsmit.home.xs4all.nl/bmp/bmp-tlv-encoding.zip
In the draft I have proposed a number of flags that can be reported
together
with each route. Maybe people have ideas what other flags could be
useful.
I plan to only include descriptions of 1-bit flags in this draft. More
elaborate information, like why a route was rejected by policy, or why
a route did not win the best-path selection, can be reported in separate
TLVs.
Which would require other drafts to describe in detail.
I think there is one issue that needs more discussion.
How should we report events where a route's attributes or state changes,
without the neighbor having sent that route ? E.g. the provider changes
a policy, and now the post-policy attributes change. If BMP just
re-reports
the route with new attributes, the bmp-collector doesn't know whether
the
route was newly received, or whether the ingress-policy changed. The
same
confusion can happen when a BGP route won best-path selection, and then
later a better route is received. Or when BGP installed the best route
in the global routing table, but that route got overwritten by a route
from another source with a better admin-distance.
Feedback (private or on this list) is much appreciated.
My apologies that I could not be present in Montreal.
Thanks,
henk.
====
Example of a BMP route-monitoring message with the new tlv-encoding:
bmp hdr : 00 00 00 A4 07
peer hdr : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 64 01 03 01 00 00 00 64 64 01
01 01 5B 4F 0E CF 00 0C C7 70
tlv hdr : 00 02 00 02
bmp flags : 55 26
tlv hdr : 00 01 00 6A
bgp hdr : FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
00 6A 02
bgp update: 00 00 00 53 40 01 01 00 40 02 06 02 01 00 00 00
64 80 04 04 00 00 00 6F C0 10 08 00 02 00 16 00
00 00 DE 80 0E 31 00 02 80 18 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 FF FF 64 01
03 01 00 98 7F FF F1 00 00 00 16 00 00 00 DE 00
23 00 23 00 23 00 23
BMP type "Route Monitoring In", length 164 (msg 20)
Peer 100.1.3.1, type Global, AS 100, flags 0x00
Flags: pre valid accept best not-rtm asn4 no-pathid
BGP UPDATE length 87
withdrawn at 0 length 0
path attributes at 2 length 83
path attr ORIGIN at 4 flags 0x40 (transitive) len 1
ORIGIN IGP
path attr AS_PATH at 8 flags 0x40 (transitive) len 6
AS_PATH 100
path attr MULTI_EXIT_DISC at 17 flags 0x80 (optional) len 4
MULTI_EXIT_DISC 111
path attr EXTENDED_COMMUNITIES at 24 flags 0xc0 (optional
transitive) len 8
EXTENDED_COMMUNITIES
path attr MP_REACH_NLRI at 35 flags 0x80 (optional) len 49
MP_REACH_NLRI
NEXT_HOP: ::ffff:100.1.3.1
AFI IPv6 SAFI mpls-labeled VPN
mp_nlri (152 bits) label: 0x7ffff1, rd: 22:222, 23:23:23:23::/64
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
