mpls-linux-general

[mpls-linux-general] Integration into kernel.

[Iain B. <zen...@ze...>]

James,

Have you considered attempting to get your MPLS support into the kernel
???

Have you contacted David Miller or Alexy about it ???

Do you have any thoughts about getting it integrated into the kernel ,
and if so, what are they ???

I think i would be good to eventually have full support for MPLS in the
kernel. I guess it needs more roleout from the big players to really
start the ball rolling, but ......


Inquiring minds want to know on a slow friday evenning in the UK :)

Re: [mpls-linux-general] Integration into kernel.

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

Hello,

On Fri, Aug 23, 2002 at 07:51:07PM +0100, Iain Barnes wrote:
> James,
> 
> Have you considered attempting to get your MPLS support into the kernel
> ???

I have considered it.  I even talked with the folks on netdev at one point.
At that time I knew I would have problems getting them to accept my changes
to the IPv4 code.  Since that time I have re-written the IPv4 -> MPLS
layer.  Mybe it's time to resume a conversation with the netdev folks.

The main question is how stable mpls-linux-1.1xx?  I can think of one more
"feature" that needs to be implemented before I will try and get netdev
to integrate this: admining down an interface needs to remove all of the
outgoing labels from thet interface, thus releasing all references to that
interface.  Anything else?

> Have you contacted David Miller or Alexy about it ???
> 
> Do you have any thoughts about getting it integrated into the kernel ,
> and if so, what are they ???
> 
> I think i would be good to eventually have full support for MPLS in the
> kernel. I guess it needs more roleout from the big players to really
> start the ball rolling, but ......
> 
> 
> Inquiring minds want to know on a slow friday evenning in the UK :)

I see your friday evening is about as exciting as my saturday afternoon :-)

Jim
-- 
James R. Leu

[mpls-linux-general] MPLS-Linux 1.160 and kernel integration

[<pim...@in...>]

Hi James,

I just tried MPLS-Linux 1.160 with the RSVP daemon and it seems that
things are stable now (I havent been able to crash the kernel so far).
Joy!

Not that I rely on it but:
ipt_MPLS.c does not compile because it uses a two argument
mpls_set_nexthop()
/usr/src/mpls-linux-1.1/patches# grep mpls_set_nexthop linux-kernel.diff
+void mpls_set_nexthop(struct rtable*, struct fib_result*, u32);
+               mpls_set_nexthop((*pskb)->dst,mplsinfo->key); <---
offending line
+                       mpls_set_nexthop(rt,res,itag);

About the kernel integration: we (as in dsMPLS) dont need additional
features.
Note that the code freeze for 2.5/2.6 is at October 31. So aiming for
2.7/2.8 seems more realistic.

Pim.

-- 
Pim Van Heuven            Ghent University - IMEC
Department  of  Information  Technology   (INTEC)
Sint-Pietersnieuwstraat, 41 B-9000, Gent, Belgium
pim...@in...
        DiffServ/MPLS(RSVP-TE) for Linux:
        http://dsmpls.atlantis.rug.ac.be

Re: [mpls-linux-general] MPLS-Linux 1.160 and kernel integration

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

On Wed, Aug 28, 2002 at 04:48:14PM +0200, pim...@in... wrote:
> Hi James,
> 
> I just tried MPLS-Linux 1.160 with the RSVP daemon and it seems that
> things are stable now (I havent been able to crash the kernel so far).
> Joy!

This is a good thing :-)

> Not that I rely on it but:
> ipt_MPLS.c does not compile because it uses a two argument
> mpls_set_nexthop()
> /usr/src/mpls-linux-1.1/patches# grep mpls_set_nexthop linux-kernel.diff
> +void mpls_set_nexthop(struct rtable*, struct fib_result*, u32);
> +               mpls_set_nexthop((*pskb)->dst,mplsinfo->key); <---
> offending line
> +                       mpls_set_nexthop(rt,res,itag);

Thank you for point this out.  I will fix it.

> About the kernel integration: we (as in dsMPLS) dont need additional
> features.
> Note that the code freeze for 2.5/2.6 is at October 31. So aiming for
> 2.7/2.8 seems more realistic.

Do you have any additional code that you add to the base mpls-linux
kernel patch?  I know at one point there were some additions that dsMPLS
needed.  Is this still the case?

Have you tried creating a zebra front end to your RSVP-TE implementation?
Would you be interested in such an endevor?  I have a decent start on a
front end to my LDP implementation and the beginings of a static LSP
implementation.  I think I have worked out many of the issues with adding
"MPLS" routes to the zebra RIB, and having BGP or other routes resolve
their nexthops correctly.

Either way, one of these days I'll get around to setting up your code and
playing around with it :-)

Keep up the good work.

Jim
-- 
James R. Leu

Re: [mpls-linux-general] MPLS-Linux 1.160 and kernel integration

[Pim V. H. <pim...@in...>]

On Wed, 2002-08-28 at 17:55, James R. Leu wrote:
> On Wed, Aug 28, 2002 at 04:48:14PM +0200, pim...@in... wrote:
> > Hi James,
> > 
> > I just tried MPLS-Linux 1.160 with the RSVP daemon and it seems that
> > things are stable now (I havent been able to crash the kernel so far).
> > Joy!
> 
> This is a good thing :-)
> 
...
> 
> Do you have any additional code that you add to the base mpls-linux
> kernel patch?  I know at one point there were some additions that dsMPLS
> needed.  Is this still the case?
No, we now have counters and great Diffserv support. 

We still need to patch the kernel for two reasons:
* prevent dsmark from copying the DSCP to tcindex (is done by
EXP2TCINDEX)
* a hack to map DiffServ over IP and DiffServ over MPLS traffic to the
same queue ("tc filter" insists on having a protocol field)

But I dont think they belong in your MPLS patch, do they? These issues
only arise if you want to have a mixed Diffserv over IP and MPLS. (And
you really want that because you want a separate control packet(=IP)
queue.)
> 
> Have you tried creating a zebra front end to your RSVP-TE implementation?
> Would you be interested in such an endevor?  
It sounds interesting to have direct access to the routing tables and
even more powerfull the link state database. (I have written papers
about and developed a scheme where you can reroute LSP very fast based
on the topology information called FTCR). Also having the same CLI for
RSVP and OSPF also seems like a huge plus. 

Problem is that my time is pretty limited and first on my to do list is
getting L-LSP support more or less stable and released.

> I have a decent start on a
> front end to my LDP implementation and the beginings of a static LSP
> implementation.  I think I have worked out many of the issues with adding
> "MPLS" routes to the zebra RIB, and having BGP or other routes resolve
> their nexthops correctly.
> 
> Either way, one of these days I'll get around to setting up your code and
> playing around with it :-)
Great, let me suggest that you wait for the 0.70-rc1 release which comes
with MPLS 1.160.
> 
> Keep up the good work.
Yes, you too, we really appreciate your work. 

Pim.
> 
> Jim
> -- 
> James R. Leu
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Jabber - The world's fastest growing 
> real-time communications platform! Don't just IM. Build it in! 
> http://www.jabber.com/osdn/xim
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
> 
> 
-- 
Pim Van Heuven            Ghent University - IMEC
Department  of  Information  Technology   (INTEC)
Sint-Pietersnieuwstraat, 41 B-9000, Gent, Belgium
pim...@in...
        DiffServ/MPLS(RSVP-TE) for Linux:
        http://dsmpls.atlantis.rug.ac.be