I don't know about the global RIB, but one thing that should be modeled is the box within which all the RIBs exist.
All the RIBs share various resources/objects within the box. Examples are: 1. power supply: if it dies, all the RIBs die. 2. Physical ports. Any RIB can bind to any of them or any VLANs on them. 3. BGP L3VPN sessions: BGP sends the routes from a bunch of VRFs (RIBs) over a single BGP session. 4. Tunnels: MPLS, IPSec, GRE, etc. The RIBs on the box have access to all of them. The RIBs in a box, but not RIBs in a different box have access to all the resources in the box. -- Jakob Heitz. ________________________________ From: [email protected] [[email protected]] on behalf of Russ White [[email protected]] Sent: Monday, 29 July 2013 1:26 PM To: 't.petch'; 'Nitin Bahadur'; Acee Lindem; 'Joel M. Halpern' Cc: [email protected]; 'Alia Atlas' Subject: Re: [i2rs] rough consensus? was Call for WG Adoption:draft-nitinb-i2rs-rib-info-model-01 (ends Aug 12) > After decades of working with router models in the IETF, my ideas are > probably rather fossilised, but I think I see some agreement that at one end > of the router, there are data structures that are passed to the silicon to use in > deciding where to forward packets; while at the other end, there are > instances of routing protocols sending and receiving data, maintaining > protocol specific data structures as a BGP RIB or OSPF link state database, and > processing it in order to derive one or more best routes within the purview > of that protocol instance:-) The problem is there is no longer "one" database that's passed to the silicon to make an actual forwarding decision --with virtualization, specifically, there's (potentially) a different set per interface, and hence there's a different "RIB" per topology behind these different forwarding table entries (though I hate to use the term "RIB" here). So when you look up a specific destination, you must not only specify the destination, but also the context within which that destination lives. The question becomes --do you want to have something like this: (Context1,10.1.1.0/24) (Context2,10.1.1.0/24) And call that the "RIB," which lives at the top level of the hierarchy? If so, then what do you call the table that lives exclusively in context 1 (or 2), and has a route to 10.1.1.0/24, but is not even aware of other routes to that same destination address because it has no access to the tables in other contexts? This second table is what's traditionally called "the RIB," in my experience. While different people have different experiences, I don't know of anyone who would call the combination of all forwarding table entry contexts into one large table the "RIB." A second way to look at this, I think, is in asking what question you want to be able to ask. Do you want to say: "Find me the route in context 1 that leads to 10.1.1.0/24?" Or do you want to say, "Step 1: select context 1. Step 2: Find route to 10.1.1.0/24." Or are we asking for: "Find every route to every possible 10.1.1.0/24 no matter what the context is?" The third question makes no sense to me, as I don't see anything useful you can do with that information. I'm open to suggestions, I just can't think of anything off the top of my head I'd ever want to use that information for, because (Context1,10.1.1.0/24) is actually a completely different destination than (Context2,10.1.1.0/24) --they're only related by their destination address, not by the physical or logical topology in any way. :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
