Hi Jon,
Some answers inline.
Regards,
neale
-----Original Message-----
From: Jon Loeliger <j...@netgate.com>
Date: Tuesday, 29 August 2017 at 20:40
To: "Neale Ranns (nranns)" <nra...@cisco.com>
Cc: vpp-dev <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Static Route Data API Data Structures
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?
Yes.
It was my choice to keep the unicast and multicast table-id the same within a
given VRF. I thought that to be the simpler approach. It saves the interface
being bound twice..
> 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?)
as you say, when you create a table you specify the AFI
Any checking done to prevent inter-family mixing in one table?
If you then add a route of the wrong AFI to that table one of two things will
happen;
1) The route will be added to the table for that AFI that happens to have that
same ID
2) You’ll get a no-such-table error
Or is that up to convention and enforcement by the API user?
GIGO
> 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).
Yes.
> 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?
I (individually) would be ☺
And is "table id" the name? Not anything more descriptive,
such as "Route Table Id"?
IMO if the context is clear that the API is related to IP, then table-id is
descriptive. But, otherwise, or even if you think the context is clear, I’d be
happy with ip_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?
Yes.
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’d hope they are really after a table-ID, given that there is no API for the
conversion and know way I can think of that the client would learn a FIB-index.
(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.)
ip_fib_dump could probably use some TLC…
> 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.
Origin or route source, that’s fine semantics. BGP and OSPF we might consider
to be separate route sources, but since BGP and OSPF processes would be
external to VPP they would both programme routes via the API so to VPP-FIB
they’d both be the same API ‘source’. But LISP/DHCP internally are also route
sources.
> FIB resources are only completely free’d was there are no more sources
> that are referencing it.
And that is internally managed, right?
Yes.
> 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?
Route addition and interface binding are completely independent (so can happen
in any order and as many times as you like).
> 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?
yes
Table continues to exist if last route is deleted or there were no routes
in the table from the onset, right?
Correct. The table is only deleted once the ip_table_del_add API is called.
> 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. :-)
Thank you.
/neale
jdl
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
