Inline with [Shunwan] Thanks, Shunwan
-----Original Message----- From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Jeffrey Haas Sent: Friday, October 12, 2018 5:23 AM To: Tim Evens (tievens) <tiev...@cisco.com> Cc: grow@ietf.org Subject: Re: [GROW] bmp loc-rib monitoring scope question (was Re: I-D Action: draft-ietf-grow-bmp-local-rib-02.txt) [Trimming original thread to re-ask my core question.] On Thu, Oct 11, 2018 at 09:18:17PM +0000, Tim Evens (tievens) wrote: > The local RIB in BMP should only contain what is/would be used/installed. >From where? BGP's best route? The routing table's active route? > In other words, the local rib sent via BMP should not contain the > suppressed prefixes that were not installed due to another routing > protocol/direct/static having a better preference. Which ties into the RFC question about where other protocols are injected into the Decision Process. If you read the RFC as literally saying it's injecting it into the Decision Process (section 9.4), the LocRib should be the best route and thus the active route regardless of whether it was learned from BGP or not. [Shunwan] IMO, the LocRib should include selected and used routes. We can consider some concrete examples. Example 1: If a router enable six parallel load balancing, and now there are 8 available candidate routes for one destination D. In this case, there will be 6 routes of the same destination D exist in the Loc-RIB, but only one of them is the best route. Example 2: If we enable BGP Fast Reroute (FRR) in a router, then there may exist a best route and a backup/alternate route in BGP for one destination D. In this case, there will be 2 routes of the same destination D exist in the Loc-RIB, but only one of them is the best route. Is my understanding right? Thanks again, Shunwan [rest left in for future context] -- Jeff > I think we should > allow the implementation to suppress the inactive or to advertise the > inactive prefixes. We can use a per-peer flag to indicate that the > NLRI's in the RM/BGP UPDATE are suppressed due to another routing > protocol/direct/static having better preference. We'll also need to > add a new INFO TLV in the PEER UP to indicate the expected conveyance > of inactive/rib-failure NLRI's. > > Unless others have hardship about adding this, I can do an update. > > > Thanks, > Tim > _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
