Thread: [mpls-linux-devel] neigh_table_find removed in 2.6.2
Status: Beta
Brought to you by:
jleu
From: Ramon C. <cas...@in...> - 2004-02-06 13:46:31
|
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... |
From: James R. L. <jl...@mi...> - 2004-02-06 14:04:28
|
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... |
From: Ramon C. <cas...@in...> - 2004-02-06 14:16:55
|
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. |
From: James R. L. <jl...@mi...> - 2004-02-06 15:05:20
|
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... |
From: Ramon C. <cas...@in...> - 2004-02-06 16:17:35
|
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... |
From: James R. L. <jl...@mi...> - 2004-02-06 16:28:16
|
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... |