----- Original Message ----- From: "Russ White" <[email protected]> To: "'Nitin Bahadur'" <[email protected]>; "'Acee Lindem'" <[email protected]>; "'Joel M. Halpern'" <[email protected]> Cc: <[email protected]>; "'Alia Atlas'" <[email protected]> Sent: Monday, July 29, 2013 2:10 AM > My original intent here was to provide "a name" to something that > aggregated all the routing-instances. > Obviously as many have pointed out, giving it the name of "rib" was a bad > choice. > > So we have 2 choices: > - Remove the top-level object in the grammar (rib) completelyŠand instead > start off with routing-instance. > - Rename "rib" (in the grammar) to something better :)
Let me ask this: Is there some point to the top level "rib" object? IE, would you ever use an object that encompasses every routing table entry across the box, no matter which specific VRF the route is in? To put it another way --is there any time when you might want to say, "hand me every route you have to 10.1.1.0/24, no matter what the routing context?" <tp> Russ 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:-) Then there is Something In The Middle, on which I do not see agreement, that takes some or all of the output of the other and passes it to the one. You could regard SITM as being a process with no data; or it might be useful to conceive of it as a data structure, listing all possible routes, or at least all those seen as acceptable to the individual protocol instance. If you are going to apply rules of selection, operational parameters, policy and so on, then regarding SITM as data is one way to do it. I rather expected this to be the approach of i2rs. So I am happy to see an all embracing SITM data structure, as long as its definition makes clear its relationship to the other and the one (as described above). I avoid the use of the usual terminology here for reasons that are probably obvious. Tom Petch </tp> I can't think of any reason you'd ever ask this type of question --the context of the route is something you must have to make sense of the route itself. In response to that, I'd say it's best to simply remove the top level object itself. :-) 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
