Subject: [GROW] I posted a first draft of draft-hsmit-bmp-extensible-routemon-msgs

From: Henk Smit <[email-masked]>
Date: Wed, 18 Jul 2018 13:09:39 +0200

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