Dear WG, I agree with Henk in his previous email that a new message type can be defined for carrying the local-rib.
Typically, it’s implementation-efficient to reuse the existing message type for carrying new information, however, as I try to understand the interpretation/mapping of the local-rib information into each existing message type, I find it a little bit difficult to follow. More specifically, the peer definition for the local-rib per-peer head is changed from the “actual peer” to an emulated peer. Since all peers are emulated, the associated peer up/down notifications and route monitoring messages are all fabricated. I understand that such implementation can be technically workable, but for me it’s a little bit deviated from the “monitoring” purpose of BMP. In fact, the above mentioned concerns can be solved by a straightforward idea of proposing a new message type for carrying the local-rib. Thus, we can save the inconvenience of transforming the BGP speaker–based local-rib into the peer-based format messages. Back to the new “local-rib message”, as Henk also suggested, the new message can be designed as TLV based. I think that using the TLV based format is more flexible for carrying non-route information in addition to the route information within either local-rib, rib-in or rib-out messages. For example, in order to better understand how the routing policy configured actually worked, an action/policy TLV can be defined and added to each route. The need for carrying the routing policy and actions/decisions taken has also been raised by Ruediger and Thomas in previous emails. I think it will be quite beneficial to the operators to understand how their routing policies actually worked and thus it’s worth taking the need into consideration during the BMP design. In addition, considering the format consistency perspective, except for the pre-policy rib-in, which can be encapsulated using the original BGP Update PDUs and sent to the monitoring station, all the other rib, i.e., post-policy, local-rib and rib-out, need to be first transformed from the rib format into the Update PDU format and then encapsulated with BMP headers, thus we might as well transform the rib into TLVs. Besides the above comments, I also have one more question regarding the idea of using the new Local-Rib instance peer. Different peers are emulated for different VRF instances and for different address families. Although it’s mentioned in Section 6.1.1 that different peers are emulated for multiple address families of the same local-rib, there is currently no flag in the per peer header indicating address family (Previously, in RFC7854, the flag V in the per peer header is used to distinguish IPv4 and IPv6). So can the authors explain how to distinguish different address families in both peer up/down notifications for the emulated peers? Best regards, Yunan Gu Huawei Technologies Co. Ltd Beijing IP Technology Research Division From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Job Snijders Sent: 2018年4月22日 8:28 To: Henk Smit <hhws...@xs4all.nl> Cc: grow@ietf.org Subject: Re: [GROW] The new BMP drafts and new BMP functionality 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 <hhws...@xs4all.nl<mailto:hhws...@xs4all.nl>> 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 GROW@ietf.org<mailto:GROW@ietf.org> https://www.ietf.org/mailman/listinfo/grow
_______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
