Acee, On Mon, Dec 10, 2018 at 10:45:15PM +0000, Acee Lindem (acee) wrote: > Just because a piece of information is useful doesn't necessarily mean it > should be part of the BGP local RIB. In many cases, the BGP process and > the Global RIB are deaggregated. If we wish to overload BMP with returning > the contents Global-RIB, then it should be a separate table.
Be mindful that having worked on the RFC 4271 revision, I'm a bit particular about BGP definitions and abstraction details. One of the details that was always an awkward fit was where routes entered the BGP abstract models. I've already posted it, but let's post it again: : 9.4. Originating BGP routes : : A BGP speaker may originate BGP routes by injecting routing : information acquired by some other means (e.g., via an IGP) into BGP. : A BGP speaker that originates BGP routes assigns the degree of : preference (e.g., according to local configuration) to these routes : by passing them through the Decision Process (see Section 9.1). By pedantic definition, this is how we get things into Loc-Rib. I'm not the one who chose the name of the draft we're discussing, but if we're going to talk "loc-rib", let's at least be clear. Customers want one of two use cases and I have customers who want them both: 1. The route in loc-rib as used for forwarding to avoid needing a parallel BGP session. 2. The best bgp route. The current draft, due to the way Loc-Rib is specified in 4271, isn't crystal clear in terms of what we'll get in the above case. In the loc-rib draft, section 1.1 talks about deriving the state by monitoring an adjacent system's adj-rib-in. This corresponds to 1 above, except when BGP advertises something it doesn't use for forwarding. See prior commentson the rib-out spec. Section 5 of the draft has the following: : 5. Loc-RIB Monitoring : : Loc-RIB contains all routes from BGP peers as well as any and all : routes redistributed or otherwise locally originated. In this : context, only the BGP instance Loc-RIB is included. Routes from : other routing protocols that have not been redistributed, originated : by or into BGP, or received via Adj-RIB-In are not considered. There is no "BGP Instance Loc-Rib". What I believe is intended by the authors is "The Loc-Rib in an implementation wherein the BGP routing state is segregated". The "have not been redistributed" also implies a specific implementation model that is also not necessarily congruent with 4271. And that's *FINE*. But the text needs to be cleaned up if so. That would push it up to #2 in my two cases. But for the customers that need #1? You've just told that part of the user-base "go run parallel BGP". Or, alternatively, "hey, Jeff, we're not covering your use case, copy 90% of the loc-rib draft text and add more code points". Or perhaps finally, "ah, we understand the distinction, how do we simply ship a single loc-rib draft that covers both". But that's only a conversation to have after we've gotten over the definition phase. -- Jeff _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
