[Note, message reordered and reformatted for quoting clarity] Tim,
Thank you for your patience for my response. On Tue, Nov 20, 2018 at 05:42:37AM +0000, Tim Evens (tievens) wrote: > On 11/16/18, 1:26 AM, "GROW on behalf of Zhuangshunwan" > <grow-boun...@ietf.org on behalf of zhuangshun...@huawei.com> wrote: > > Jeff Haas said: > > > I do wish to get this point resolved. We have inconsistent pressure from > > > our own customer base as to whether they want to monitor best bgp vs. > > > "please give me something to let me stop needing parallel BGP sessions > > > for active route state". > > > > [Shunwan] IMO, Section 5.2 of draft-ietf-grow-bmp-local-rib-02 describe a > > method to send best ecmp group to BMP Station. > > BMP client can signal add-paths capability to BMP Station via BMP Peer > > UP message, then BMP Station will know that the client will send multiple > > NLRI for one destination. > > That is my understanding. > > Per my limited knowledge about BMP, I don't understand why we need > > "parallel BGP sessions for active route state", Sorry. Can you explain it > > in detail? > > Best route for sure, unless add-paths is used. I would like to understand > your use-case more... When you mention the customer has to use "parallel > BGP sessions for active route state," are you saying that the customer > needs to establish multiple "monitoring" BGP peering sessions in order to > obtain what would have been available via BMP Adj-RIB-In Post Policy > monitoring? Today, customers running stock BMP (RFC 7854) often tend to have a parallel BGP peering session with their routers to monitoring stations. This permits them, in many cases, to correlate the results of BGP received paths vs. path selection. Sticking with a simplified example with BGP running its path selection solely on BGP routes, the active route in the system's RIB may end up being non-BGP. Typical examples are static routes, or IGP routes winning out over BGP routes. I.e. "administrative distance". The route used for forwarding will be the active route in the RIB. BGP itself will advertise the active route in most implementations in most circumstances. The issue in a simplified example: If the active route for a destination is a static route, a customer may want to know this vs. the best BGP route. This is needed to check why forwarding is happening as expected. Why not use rib-out? Because other BGP features may cause a route that isn't the active route to be sent. E.g. best-external. The problem is thus: Does the customer want to receive a loc-rib feed vs. the route being actively used for forwarding, or do they want to see the best BGP route? We've had requests for both, depending on use case - typically "BGP monitoring and path analysis" vs. "forwarding validation vs. route selection". A further complicating factor is that some implementations let non-BGP routes be effectively injected into the BGP route selection process in ways that make "best route using BGP route selection" somewhat more ambiguous. --- Add-paths is also somewhat ambiguous, I think, in a loc-rib context as it is specified in the current draft. If we are to send only the contents of the rib, is the path-id intended to reflect the learned path-id from a given peer's route? If so, I'm a bit confused by Shunwan's point about ecmp groups. This is because in order to safely send the ecmp contributors via add-paths encoding, we must overwrite the received path-id and locally generate it. Clearly we do this in a rib-out context, but that's not what I thought we were discussing here. -- Jeff _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
