On Tue, Aug 29, 2017 at 4:21 AM, Neale Ranns (nranns) <nra...@cisco.com> wrote: > Hi Jon, >
Neale, > By ‘IP’ in this context we mean IPv4 and IPv6 and unicast and multicast > (known as sub-address families or SAFIs). To provide this separation we > therefore need 4 ‘tables’ per-VRF, one for each SAFI. You say 4 here, but really we implement 2, one for IPv4 and one for IPv6. So, an interface can be bound to multiple tables. But is it limited to one IPv4 and one IPv6 table? > A ‘table’ in this context is the well known longest-prefix matching DB. > Tables are known by a unique per-AFI ID (note per-AFI not per-SAFI, > so IPv4 unicast and multicast share the same table-id). A table doesn't know its Address Family, except by the inspection of the types of routes within it, right? (But both uni- and multi-cast routes are possible in just one table, right?) Any checking done to prevent inter-family mixing in one table? Or is that up to convention and enforcement by the API user? > It is the client’s responsibility to associate unique table IDs to tables > within all of its VRFs. Ah, there. Only the external client (management agent) maintains any notion of actual Virtual Routers. To that end, multiple routing tables are supplied for client use as it sees fit. > The client is free to choose the table-ID from the full u32 range. > So, bottom line, in the context of IP forwarding[,] a table (and its > associated ID) refer to an instance of a LPM DB. Right. But prefix management is left up to something else (routing protocol). > Despite code comments and variable naming, VPP does not maintain > the concept of a VRF, i.e. it does not maintain a grouping of ‘tables’. This is an important observation. > At the client interface VPP deals only with table IDs – i.e. an identifier > that > the client provided for a given LPM DB. All APIs that claim to accept a > VRF index should be renamed to accept an IP table ID. Would you (collectively) be receptive of patches to that end? And is "table id" the name? Not anything more descriptive, such as "Route Table Id"? > As with all things VPP the allocation of the data-structure that represents > the LPM-DB comes from a memory pool. This data-structure thus has an > associated pool index – this is the FIB index. So, there is a one to one > mapping between the externally visible and client assigned ‘table ID’ and > the internal use only ‘FIB index’. Both are a u32, neither are strictly typed… Ah, I see. Mapping in one direction is pool index, and a hash table in the other direction? As some APIs appear to want the FIB index, is there an API to do the FIB Id lookup for a Table Id? (I'd posit that either needs to be one, or the APIs that accept a FIB Id need to be converted to Table Id.) Or, are all those references to a FIB Id really *also* supposed to be a Table Id? (I'm not seeing this line up with the API call ip_fib_dump yet. Does it? If it does, and I see that it has route details in the fib_path, the table id is lost. So no client-side FIB-to-TableId mapping can be established.) > With regards to the creation of tables, I’m currently working on the API > you discovered – ip_table_add_del. With this API the client instructs VPP > to add/delete a ‘table ID’ (as discussed above). OK, good. > The VPP FIB has the concept of ownership or ‘sourcing’ of its resources. > Sources can be external (i.e. the CLI or the API) or internal (e.g. LISP > and DHCP). Ah, "source" was confusing here. We mean "origin" and not "route source". How the FIB came to exist. > FIB resources are only completely free’d was there are no more sources > that are referencing it. And that is internally managed, right? > My intention with the table add/delete API is that the client can add the > table then insert routes and bind interfaces. Specifically in that order? Does the table have to be fully route-populated at the time it is IF-bound? Or will a later route addition/deletion be factored into that IF's forwarding properly? > If the client then deletes the table its routes will be purged. The table will > then be deleted iff it held the last reference. Full table. Good. Individual route additions/removals to that table OK too? Table continues to exist if last route is deleted or there were no routes in the table from the onset, right? > With the introduction of this API VPP will insist that it has been called > to create the table before any routes or interfaces refer to it. Seems like a correct behavior. > The current behaviour is that tables can be created either by setting an > interface into that table, or by setting the ‘create_vrf_if_needed’ flag in > a route add. There is no means to delete it, hence my new API work. I see. OK, I'll help push to get your patches accepted. :-) jdl _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
