Hi Tom, Thanks for your comments. Please see inline below.
On 7/26/13 5:39 PM, "t.petch" <[email protected]> wrote: >I oppose adoption of this I-D. The use of terminology seems >incompatible with the use of the same terminology elsewhere and, >arguably, contradicts the charter. > >For example, this I-D says > >" A RIB > contains one or more routing instances. > A routing instance, in the context of the RIB > information model, is a collection of routing tables, interfaces, and > routing parameters. > The routing tables specify how incoming > traffic is to be forwarded." > >whereas the charter clearly differentiates the RIB, which is the subject >of this WG, from the FIB, which is not. The reference here to routing >tables sounds rather like a FIB. Regarding "routing tables" as an element of the FIB, then I think it's a terminology mis-understanding. A routing-table (as per this draft) is something that is local to the control plane and has nothing to do with the forwarding plane. A routing-table (as per this draft) is a database containing route information. Now if this terminology conflicts/confuses with how some hardware vendors use the same term, I would be happy to change the name to something else (maybe call it a RIB). I hope you now understand why I did not think of it as a FIB construct. >And the I-D places heavy emphasis on interfaces which again seems to >have >nothing to do with the charter. It's unclear to me how you program a route without an associated interface where the data gets sent out. For example in OSPF, if one learns a route via OSPF, you know from which neighbor you learnt it from and you know the interface associated with it as well. That's how the router is able to send the packets out to the destination. In the case of DDOS mitigation, you might want to add a route that drops packets from most offending prefixes. But for some of the offending prefixes, you might want to forward the packets to a monitoring station (a station that is directly connected to the router and does not speak IGP). So the only way is to add a route pointing to an interface. This is very similar to how static routes are configured on routers today. AFAIK, a lot of operators use static routes and if we get rid of the "interface" object, then a whole class of static routes cannot be programmed using the RIB IM model. Similarly, you won't be able perform things like RPF checkŠwithout which multicast will be crippled. >This topic has surfaced several times on several WG lists, none of which >has produced an agreed document, but the best one would appear to me to >agree that there are processes, not just data, and that these processes >are tied to routing protocols, and that the data thereof needs to be >split into three > - a RIB (in the sense that I most often see it used) containing the >data used by a protocol process instance This is what is contained in the contents of the "routing table". >- a central database of consolidated routes, sometime referred to as >RIB2 This is not necessarily exposed to the external controller. At least it's not easily possible in the current information model. The RIB IM draft basically calls for programming routes in tables (say RIBs) and if a route gets selected as the best route (Eg. For a given IP prefix), then the external controller is informed that the route it programmed is now installed and will be used by silicon for forwarding). >- what gets used in forwarding, usually by the silicon. This should not be exposed to the controllerŠsince it contains forwarding details as well. Thanks Nitin _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
