Hi Jeff, I'm also sorry for the delay. There have been some year end commitments that have taken my available cycles.
See inline marked [tievens] On 12/10/18, 2:32 PM, "Jeffrey Haas" <[email protected]> wrote: [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" <[email protected] on behalf of [email protected]> 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. [tievens] That sounds like what we have been doing as well... basically trying to use Adj-RIB-Out to monitor local-Rib, which hasn't worked too well, especially with originated in bgp data. 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". [tievens] IMO, the "active route in the system's RIB" is more of the FIB table, where it takes into account conflicting sources of data (ISIS, OSPF, BGP, static/direct, and any variance of multi-instances). This convergence of route sources with preference/selection, IMO, is out of scope for BGP monitoring. BGP monitoring by itself is very important to monitor. The monitoring station (bmp receiver) can apply admin preference between the available sources of data (bgp-ls with ISIS and OSPF) to identify which one is used over the other, but it'll never replace the "system rib/fib." BGP Loc-RIB is just what BGP has across all afi/safi's. IMO, we will always need to monitor BGP, ISIS, and OSPF, but we also do need FIB. I see FIB monitoring including egress interface/port granularity (lag port, not just the lag interface), source identifier of protocol and protocol instance, etc. Something will have to be done with FIB monitoring to also address the hashing/lb based on l4/input/etc. The route used for forwarding will be the active route in the RIB. [tievens] BGP Loc-RIB is what the router has in, or available to, BGP that would be sent to a peer. BGP itself will advertise the active route in most implementations in most circumstances. [tievens] Agreed. There will be cases where another protocol will be preferred over BGP's learnt entry. BGP will still advertise (to peer and Loc-RIB) prefix A via next-hop C but the router is actually forwarding prefix A via next-hop Z based on another protocol having better preference. 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. [tievens] Agreed, but this is not "BGP loc-RIB" monitoring. This would be FIB or System RIB monitoring which is different. This in IMO requires egress interface level info, specifically to address the issue with lag ports/members. This level of monitoring also does not need all the BGP attributes or be required to conform to BGP... What's available and needed depends on the route source. For example, ISIS TLV's, static route locally significant attributes, etc. The FIB/System RIB level monitoring can be simpler than BGP encoding with more flexible attribute conveyance... I hate to say it because I prefer BGP in most cases, but System/FIB monitoring with multiple route sources to consider is, IMHO, better served with flexible models/schemas. 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". [tievens] I think the confusion is that loc-rib is NOT the router's FIB. It is the BGP loc-RIB and will only convey what's in/available to BGP as it would send out (e.g. rib-out). Adj-RIB-Out and Loc-RIB are very similar, which is sometimes confused. The key difference between Adj-RIB-Out and Loc-RIB (context is BGP) drafts are that Loc-RIB does not require you to have an actual peer with a remote system and it does not suffer from transport or afi/safi restrictions that would otherwise be imposed by a peering session (e.g. IPv4 vs IPv6). 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 [email protected] https://www.ietf.org/mailman/listinfo/grow
