mpls-linux-devel

[mpls-linux-devel] neigh_table_find removed in 2.6.2

[Ramon C. <cas...@in...>]

Hi,

Little question here: neigh_table_find has been removed in 2.6.2

The original goal was to manage mpls_dsts but reusing the AF_INET
AF_INET6 neighbour tables (lookup a neighbour and hold it in the mpls_dst)

The problem is that now I don't see how we can do this... We should not 
access the neigh_tables list & lock directly. Maybe we should manage our 
own neighbours and a AF_MPLS neighbour table... I'm starting to think that 
this is the best approach, since we can even cache hh objects with 
ETH_P_MPLS_UC....

Thoughts? Maybe we should start bugging ne...@os... for comments. 

Regards,
R.



RFC: 
        /* Set next hop MPLS attr */
        memcpy(&md->md_nh,nh,sizeof(struct sockaddr));

        /*
         * Lookup for the next hop (neighbour) in the AF_INET/AF_INET6
         * neighbour table. (neigh_table_find removed in 2.6.2)
         */

	tbl = neigh_table_find (....)

        /*
         * AF_INET neighbour keys are their addr.
         * Look for the neighbour (create if needed)
         * (neigh_lookup & neigh_create hold a ref)
         */
        md->u.dst.neighbour = __neigh_lookup(tbl, data, dev, 1);


// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Ramon Casellas - GET/ENST/INFRES/RHD/A508 - cas...@in...

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

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

I implemented neigh_table_find.  True their is no refcnting of anything
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 hh_cache
will never work because the contents of the MPLS header is not the
same for every packet that traverses an LSP (TLL and EXP), so the only
info we would get from MPLS neighbour table is the exact information that
we get from the IPv[4|6] tables.  I see nothing to gain by implementing
a MPLS neighbour table.  I think the correct path is to add refcnting
to neigh_table.

Won't other protocols needs this as well?  Think of IPv6 routes that point
to IPv4 nexthops or vice versa.

On Fri, Feb 06, 2004 at 02:46:16PM +0100, Ramon Casellas wrote:
> 
> 
> Hi,
> 
> Little question here: neigh_table_find has been removed in 2.6.2
> 
> The original goal was to manage mpls_dsts but reusing the AF_INET
> AF_INET6 neighbour tables (lookup a neighbour and hold it in the mpls_dst)
> 
> The problem is that now I don't see how we can do this... We should not 
> access the neigh_tables list & lock directly. Maybe we should manage our 
> own neighbours and a AF_MPLS neighbour table... I'm starting to think that 
> this is the best approach, since we can even cache hh objects with 
> ETH_P_MPLS_UC....
> 
> Thoughts? Maybe we should start bugging ne...@os... for comments. 
> 
> Regards,
> R.
> 
> 
> 
> RFC: 
>         /* Set next hop MPLS attr */
>         memcpy(&md->md_nh,nh,sizeof(struct sockaddr));
> 
>         /*
>          * Lookup for the next hop (neighbour) in the AF_INET/AF_INET6
>          * neighbour table. (neigh_table_find removed in 2.6.2)
>          */
> 
> 	tbl = neigh_table_find (....)
> 
>         /*
>          * AF_INET neighbour keys are their addr.
>          * Look for the neighbour (create if needed)
>          * (neigh_lookup & neigh_create hold a ref)
>          */
>         md->u.dst.neighbour = __neigh_lookup(tbl, data, dev, 1);
> 
> 
> // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> // Ramon Casellas - GET/ENST/INFRES/RHD/A508 - cas...@in...
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel

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

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

[Ramon C. <cas...@in...>]

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.

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.

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...

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

[Ramon C. <cas...@in...>]

On Fri, 6 Feb 2004, James R. Leu wrote:

> 
> 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.


Right, right, I know, the hh_type is set when the neighbour is being 
initialized, and from the type in the dst ops protocol (which is MPLS).
(and since we override the dst, thinks work fine).

This is not necessarily wrong, but my point is that we do not have an 
homogeneous neighbour-hh_object with a single address family (and I 
don't know if we should)... I was just thinking vaguely about the 
possibility of doing like in DECnet of IPv6, where they do manage their 
own set of neighbours and a neighbour table. 

Maybe we should, if later we want to transport other payloads, we should
have a uniform view of *neighbour LSRs* for AF_MPLS (within the scope of a
well defined Layer 2 technology, agnostic to the layer 3 protocol). The L3 
details are left for mpls_dsts.

Well, that's just Food for thoughts for MPLs-Linux 3.0 :), but my issue 
about not increasing the refcount of the neighbour table (although a rare 
event) applies

thanks for reading...

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

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

I agree that the current use of the neighbour table without holding
some sort of refcount is "a bad thing" and should be fixed.  I will look
into this tonight.

On Fri, Feb 06, 2004 at 05:17:30PM +0100, Ramon Casellas wrote:
> On Fri, 6 Feb 2004, James R. Leu wrote:
> 
> > 
> > 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.
> 
> 
> Right, right, I know, the hh_type is set when the neighbour is being 
> initialized, and from the type in the dst ops protocol (which is MPLS).
> (and since we override the dst, thinks work fine).
> 
> This is not necessarily wrong, but my point is that we do not have an 
> homogeneous neighbour-hh_object with a single address family (and I 
> don't know if we should)... I was just thinking vaguely about the 
> possibility of doing like in DECnet of IPv6, where they do manage their 
> own set of neighbours and a neighbour table. 
> 
> Maybe we should, if later we want to transport other payloads, we should
> have a uniform view of *neighbour LSRs* for AF_MPLS (within the scope of a
> well defined Layer 2 technology, agnostic to the layer 3 protocol). The L3 
> details are left for mpls_dsts.
> 
> Well, that's just Food for thoughts for MPLs-Linux 3.0 :), but my issue 
> about not increasing the refcount of the neighbour table (although a rare 
> event) applies
> 
> thanks for reading...
> 

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