Hi Yunan Gu, On 4/23/18, 5:18 AM, "GROW on behalf of Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <mailto:[email protected] on behalf of mailto:[email protected]> wrote: 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.
<tievens> I believe what you wrote is what we are proposing. See below response to emulated peer. Implementations vary and how "one" generates the BMP common + peer header as it is not dictated in RFC7854. For example, as per the current RFC7854 draft, for efficiency the peer header only needs to be initialized once (cached) at PEER UP. This includes open messages, peer type, peer flags, RD, info TLV's, etc. In this case, setting the message type or flag is no more efficient. <tievens> Emulated peer is a pseudo logical peer that "represents" the local-rib. Implementations that do this today, leverage "existing code," requiring little effort to implement local-rib. They do this by generating a local-rib peer that is like any other peer with the exception of no state/session or peer type (iBGP vs eBGP) restriction. The update-group (of 1) adj-rib-out for this peer represents the local-rib. The draft keeps it open to allow the sender to apply filters on this peer, such as to exclude any IBGP learnt prefixes. In this case with filters, a single flag indicates the conveyed local-rib does not represent the entire set. All the drafts (7854, local-rib, adj-rib-out) do not attempt to address configuration or policy conveyance, other than simple hints via INFO TLV's. IMHO, attempting to convey and consequently standardize on policy configuration goes into the weeds. This includes even a simple attempt to convey just the policy names, as names, order, actions, etc... are not standard over all platforms/vendors. While I completely agree operators need to know which policy results in which change/filter/etc... the conveyance of such does not have to be via BMP. I would rather use BMP to monitor and measure the results and use a global unique ID for correlation of peers to policy/configuration. This would enable monitoring to be correlated correctly to YANG/Openconfig configurations and policies. IMO, it's not just the egress NLRI/attribute policies, it's all of the configuration that makes up the policy, such as setting next-hop self, add-paths, ... We need more than peer specific policy config, we need the rest of the configuration (e.g. VRF imports/exports). I do not believe we should overload BMP with configuration and policies conveyance. BMP is to monitor BGP (NLRI's and attributes) not convey policies or configurations. === 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. <tievens> First, changing the peer-header to TLV's is a fundamental change to RFC7854 peer header, forcing a version change. Second, this IMHO is a total scope creep for BMP as BMP is the wrong place to be conveying policies which are configurations and are vendor/platform specific. Adding policy/configuration to BMP opens the door to a whole new level of complexity with the BMP receiver now having to handle configurations/policies. This is normally handled by a SDN controller, NFV, or similar product that focuses on configuration and policy management. I do not believe those folks will appreciate that policy will now be moved from, or in parallel with, MDT/OpenConfig. <tievens> IMHO, what we need to do is not rewrite what's working to convey configuration. Instead we should add what's needed to correlate between data methods and feeds. This enables BMP to support existing and new applications that specialize in the configuration/policy domain (e.g. SDN controllers, NFV, etc.). For example, BGP-LS includes link-id's which can be used to correlate LS LINK NLRI's to logical/physical links/configurations. This is great and works well to support micro services/applications. The problem, and IMO oversight, with BGP-LS is that it's not required per the draft to include link-id's, or even implement them. This makes it horribly error prone to correlate links to configuration and other forms of telemetry (e.g. correlate LAG to member links). Yes, we need to correlate more than just policy configurations, we need to correlate telemetry interface, flow export data, etc... to BGP monitoring as well. If we follow suit with adding non-route data, where is the line in the stand? <tievens> Currently, 7854 only gives us BGP ID, RD, and Address to correlate with. While this does work in most cases, these can be overloaded/duplicated/invalid. This can result in correlation errors leading to mistrust when correlating to datasets such as telemetry and configuration. I'm leaning more towards adding a correlation unique ID (maybe associated array if needed) that enables us to correctly correlate between the related datasets (telemetry, configuration, SDN controllers). === 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? <tievens> That's an incorrect understanding of the V flag. The V flag, as defined in RFC7854, DOES NOT represent the afi/safi's conveyed. The V flag only represents the transport session address family. This is why it is only IPv4 or IPv6 as those are the only transport address families currently used. It directly is used when decoding the address within the BMP peer header. In other words, the V flag only indicates if the peer header address is IPv4 or IPv6, not the BGP update message families. Thanks, Tim _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
