Re: [mpls-linux-devel] neigh_table_find removed in 2.6.2

[James R. L. <jl...@mi...>]

On Fri, Feb 06, 2004 at 03:16:47PM +0100, Ramon Casellas wrote:
> On Friday 06 February 2004 15:04, James R. Leu wrote:
> 
> > I implemented neigh_table_find.  True their is no refcnting of anything
> 
> Ouups :*) my mistake ....
> 
> 
> 
> > it was a quick hack.  There is no easy way to implement a MPLS neighbour
> > table without completly duplicating the IPv4 or IPv6 neighbours.  A
> 
> I am not sure... not a priority, but I'll take a look.
> 
> > hh_cache will never work because the contents of the MPLS header is not the
> 
> IMHO, I thing you are wrong. No L3 info is stored on a hh_cache (only the 
> ETH_P type), and in this case the shim header "acts" like a L3. the hh_cache 
> object should only cache MAC DA, SA, and Ethertype (ETH_P_MPLS_UC) no more. 
> It is the Ethernet header only.

The current use of IPv[4|6] neighbour tables already caches the DA, SA, and
MPLS ethertype. Look at the debug output for mpls_send().  It shows
that it is using the hh cache, and the resulting packet has the correct
ethertype.

> TTL and EXP are analogous to the IPv4 header, which also changes. I *do* think 
> that we should manage hh objects.
> 
> 
> > neighbour table.  I think the correct path is to add refcnting to
> > neigh_table.
> 
> I'm not sure... I'll think about it, but for me, the correct will be to have 
> an AF_MPLS neighbour table, with mpls neighbours held by mpls dsts, with mpls 
> hh caches (sorta like decnet). True, the control plane is IPv4/ IPv6, and 
> this may mean having to code much more, but it makes sense. 
> 
> Still, justs some random thoughts...
> 
> R.

-- 
James R. Leu
jl...@mi...