1 week until Summer of Code application time
Here's a heads-up: Application time for organizations (not students) to get into the 2009 Summer of Code program is 1 week away. If you are any of these things: - potential student - potential mentor - person with an idea for a project Please mark it down at: http://www.dragonflybsd.org/gsoc2009/ It's OK to suggest an idea even if you don't have the time to mentor it. I do need more mentors names - remember, it gets you $500 in addition to helping the DragonFly project a great deal.
Re: 1 week until Summer of Code application time
It will be amazing if someone can get FreeBSD-UFS mountable (at least for read). On Tue, Mar 3, 2009 at 01:27, Justin C. Sherrill wrote: > Here's a heads-up: > > Application time for organizations (not students) to get into the 2009 > Summer of Code program is 1 week away. > > If you are any of these things: > > - potential student > - potential mentor > - person with an idea for a project > > Please mark it down at: > > http://www.dragonflybsd.org/gsoc2009/ > > It's OK to suggest an idea even if you don't have the time to mentor it. > I do need more mentors names - remember, it gets you $500 in addition to > helping the DragonFly project a great deal. > > -- Sdävtaker prays to Rikku goddess for a good treasure.
Re: 1 week until Summer of Code application time
Sdävtaker wrote: It will be amazing if someone can get FreeBSD-UFS mountable (at least for read). I didn't realize that it wasn't Should I cease doing it? OpenBSD is problematic among slices on on same-disk, but even that is apparently resolvable via disklabel editing. Haven't felt the need... yet.. Bill On Tue, Mar 3, 2009 at 01:27, Justin C. Sherrill wrote: Here's a heads-up: Application time for organizations (not students) to get into the 2009 Summer of Code program is 1 week away. If you are any of these things: - potential student - potential mentor - person with an idea for a project Please mark it down at: http://www.dragonflybsd.org/gsoc2009/ It's OK to suggest an idea even if you don't have the time to mentor it. I do need more mentors names - remember, it gets you $500 in addition to helping the DragonFly project a great deal.
Re: 1 week until Summer of Code application time
Cool projects. I am rooting for "Add redundant data storage to the HAMMER file system". Go Simon :-) On Tue, Mar 3, 2009 at 7:39 AM, Bill Hacker wrote: > Sdävtaker wrote: >> >> It will be amazing if someone can get FreeBSD-UFS mountable (at least for >> read). >> >> > > I didn't realize that it wasn't > > Should I cease doing it? > > OpenBSD is problematic among slices on on same-disk, but even that is > apparently resolvable via disklabel editing. > > Haven't felt the need... yet.. > > Bill > > > >> >> On Tue, Mar 3, 2009 at 01:27, Justin C. Sherrill >> wrote: >>> >>> Here's a heads-up: >>> >>> Application time for organizations (not students) to get into the 2009 >>> Summer of Code program is 1 week away. >>> >>> If you are any of these things: >>> >>> - potential student >>> - potential mentor >>> - person with an idea for a project >>> >>> Please mark it down at: >>> >>> http://www.dragonflybsd.org/gsoc2009/ >>> >>> It's OK to suggest an idea even if you don't have the time to mentor it. >>> I do need more mentors names - remember, it gets you $500 in addition to >>> helping the DragonFly project a great deal. >>> >>> >> >> >> >
Re: 1 week until Summer of Code application time
Hi Justin, Just want to suggest and share this idea (without mentoring) about virtual routing based on this link here http://www.ipinfusion.com/pdf/VirtualRouting_app-note_3rev0302.pdf. Although I'm not so sure if this is already implemented in the project, so just correct me if I'm wrong. Basically, virtual routing is a concept of emulating multiple instances of routing tables (RIB and FIB) intended for running multi-independent network services. Thanks, Archimedes
Re: 1 week until Summer of Code application time
On Thu, March 5, 2009 1:36 am, Archimedes Gaviola wrote: > Hi Justin, > > Just want to suggest and share this idea (without mentoring) about > virtual routing based on this link here > http://www.ipinfusion.com/pdf/VirtualRouting_app-note_3rev0302.pdf. > Although I'm not so sure if this is already implemented in the > project, so just correct me if I'm wrong. Basically, virtual routing > is a concept of emulating multiple instances of routing tables (RIB > and FIB) intended for running multi-independent network services. This sounds like work separating out the routing table between jails, or perhaps vkernels. I may be naive, however. Write this out on: http://www.dragonflybsd.org/gsoc2009/ as a potential project; there doesn't have to be a mentor attached to an idea. (not yet, anyway.)
Re: 1 week until Summer of Code application time
Justin C. Sherrill wrote: On Thu, March 5, 2009 1:36 am, Archimedes Gaviola wrote: Hi Justin, Just want to suggest and share this idea (without mentoring) about virtual routing based on this link here http://www.ipinfusion.com/pdf/VirtualRouting_app-note_3rev0302.pdf. Although I'm not so sure if this is already implemented in the project, so just correct me if I'm wrong. Basically, virtual routing is a concept of emulating multiple instances of routing tables (RIB and FIB) intended for running multi-independent network services. This sounds like work separating out the routing table between jails, or perhaps vkernels. I may be naive, however. Write this out on: http://www.dragonflybsd.org/gsoc2009/ as a potential project; there doesn't have to be a mentor attached to an idea. (not yet, anyway.) I don't really see the benefit in this. Either you combine forwarding tables into one table, or you... well, that's actually it. I guess the larger part is more on a control plane level than on a data plane level, so that would more be a xorp project, I guess. I might also miss the point completely. cheers simon
Re: 1 week until Summer of Code application time
Simon 'corecode' Schubert wrote: > I don't really see the benefit in this. Either you combine forwarding > tables into one table, or you... well, that's actually it. I guess the > larger part is more on a control plane level than on a data plane > level, so that would more be a xorp project, I guess. I might also > miss the point completely. Control plane is a trivial part, really. Forwarding plane part is much harder. Proper virtual router support as used nowadays massively (yes, really) in ISP's needs: * Completely isolated forwarding tables (this includes L2 info) - you just associate an interface with virtual router. * Sockets associated with virtual router. A process can create a socket listening 0.0.0.0:179 in particular virtual router only. Ideally some mechanism to associate a process with virtual router - all sockets created by process will be associated with this virtual router then. * The ability to reuse IP addresses and TCP/UDP ports in virtual routers. Different virtual routers can have overlapping addresses and different processes using overlapping ports. * Mechanism to forward traffic between virtual routers (and full control over the traffic). With this in place, making control plane software to support it, is quite straightforward. I have done this once although in limited way on top of Linux forwarding tables (which are lame in routing point of view, btw) with Quagga. regards, -- Hasso Tepper
Re: 1 week until Summer of Code application time
On Fri, Mar 6, 2009 at 1:32 AM, Hasso Tepper wrote: > Simon 'corecode' Schubert wrote: >> I don't really see the benefit in this. Either you combine forwarding >> tables into one table, or you... well, that's actually it. I guess the >> larger part is more on a control plane level than on a data plane >> level, so that would more be a xorp project, I guess. I might also >> miss the point completely. > > Control plane is a trivial part, really. Forwarding plane part is much > harder. Proper virtual router support as used nowadays massively (yes, > really) in ISP's needs: > > * Completely isolated forwarding tables (this includes L2 info) - you > just associate an interface with virtual router. > > * Sockets associated with virtual router. A process can create a socket > listening 0.0.0.0:179 in particular virtual router only. Ideally some > mechanism to associate a process with virtual router - all sockets > created by process will be associated with this virtual router then. > > * The ability to reuse IP addresses and TCP/UDP ports in virtual routers. > Different virtual routers can have overlapping addresses and different > processes using overlapping ports. > > * Mechanism to forward traffic between virtual routers (and full control > over the traffic). > > With this in place, making control plane software to support it, is quite > straightforward. I have done this once although in limited way on top of > Linux forwarding tables (which are lame in routing point of view, btw) > with Quagga. > > > regards, > > -- > Hasso Tepper > Thanks Hasso for explaining more information! Yes, most ISPs/NSPs are deploying virtual routing to their respective infrastructure at the edge level. I just knew that FreeBSD project is currently doing network stack virtualization http://imunes.tel.fer.hr/virtnet/, http://misc.allbsd.de/Vortrag/EuroBSDCon_2007//Marko_Zec/TUTORIAL.PDF, http://www.tel.fer.hr/zec/papers/talk-eurobsdcon-02.pdf. Archimedes
Re: 1 week until Summer of Code application time
On 2009-03-05 07:36, Archimedes Gaviola wrote: > Hi Justin, > > Just want to suggest and share this idea (without mentoring) about > virtual routing based on this link here > http://www.ipinfusion.com/pdf/VirtualRouting_app-note_3rev0302.pdf. > Although I'm not so sure if this is already implemented in the > project, so just correct me if I'm wrong. Basically, virtual routing > is a concept of emulating multiple instances of routing tables (RIB > and FIB) intended for running multi-independent network services. On the product I'm working on we have something similar (I have not studied the paper you provided in detail so I can't be sure it's the same thing) called a Routing Instance. Each routing instance is connected to an interface, but these interfaces are usually not actual physical interfaces rather they are usually VLAN interfaces. To be really useful you need some way to specify which to use which would probably mean to add some parameters when creating a socket to specify which routing instance to use. I don't want to sound negative (because I think it's a cool feature and a worthy challenge) but I don't see much use for it in DragonFly BSD. For a product such as the one I'm working on where we provide network connectivity for mobile devices where packets are to be routed to different corporate networks depending on the subscription (or some other criteria) it makes sense. We just create one VLAN for each network and all their packets use the associated routing instance. But I don't quite see the usefulness in the kinds of roles that (I imagine) people uses DragonFly BSD for. Perhaps OpenBSD would be more interested, they strike me as having more focus on being usable as an internal node in a network. -- Erik Wikström