Dear WG, I’d like to encourage the authors and stakeholders of current BMP work to assess the below feedback and get back to the working group.
Kind regards, Job On Mon, 26 Mar 2018 at 15:24, Henk Smit <[email protected]> wrote: > > 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 >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
