Mailing List Archive

* Jean-Francois Laforest <fuzzball@ipv6peer.net> wrote:

> Goals:

A vrrpd implementation would also be nice, I think.

sebastian

--
whois: sabt-ripe - phone: +49 (0)174 3420738
email: sabt@sabt.net - pgp-pubkey: 0x3B046B48

> - Full MPLS support

I'd like to submit my code at the first step towards this goal.

mpls-linux and ldp-portable: http://mpls-linux.sf.net/

--
James R. Leu

Jean-Francois Laforest wrote:
> As I said 2 days ago, I would email you with a list of functionality
> that should be implemented. Give me full feedback.
>
> Goals:
> - QoS control (Linux (HTB, CBQ, etc.), FreeBSD (ALTQ)).
> - Packet filter control (iptables, pf, ipf)
> - tcpdump access off vtysh (could be neat)
> - show device status (errors, etc... could also be route statistics, see
> netstat -ni (under bsd))
> - Full MPLS support
> - ARP functionality (monitoring arp requests, doing changes, acl, etc)
> - IP accounting functionality
> - Make vtysh the CLI of choice that can launch/kill/etc. services.
> - IPsec support.
> - Tunneling devices (gre, gif, etc.) advanced support (add, remove,
> modify)
>

Hi,

Let me somehow question the "everything under one bloated umbrella"
approach and not get carried away in the very beginning:

1)Zebra and its protocol daemons are signalling daemons and route
processors by its very nature. That should remain the "prime directive"
in Star Trek lingo. I do not advise to shift this focus towards
integration of unnecessary user-space clutter just to have a bloated
universal GUI that breaks whenever little changes to GRE or heaven knows
what are introduced at the cost of platform independence. The CLI should
never be at the center of our design consideration. I don't think it is
adwisable to administer everything network related on a UNIX box from
within Zebra.
2)Multiple routing tables are only available for Linux, hence it will
most likely be the only operating system that will benefit from MPLS
advanced features. To my knowledge there is no MPLS signaling work in
progress for BSD. I'd rather like to see multiprotocol BGP evolve then
isolated MPLS approaches.
2)Hence for the time being packet filter and IPSec should stay outside
the Zebra engine. Too complicate protocol suites and too platform
dependent (pf, ipfilter, ipfw, iptables/netfilter, ...)
It is safe to assume that the KAME implementation will be the protocol
suite of choice for almost all relevant Linux/BSD OSs starting from
Linux 2.5.x with regards to IPsec. That might improve such endeavors.
3)Let us learn from the way the ip utility under linux evolved. I do
think that here the folks did a good job of something similar than you
envision. They succeeded because they bundled *related* stuff together
but it does not concern signalling. I don't want to see IPsec
administration in the ip utility. But it should work on all platforms
and hence include the minimals set of features.
4)Tunnel devices are a nice thing and important feature that shoud go
into the CLI very soon. In fact, supporting as many interfaces and
pseudo-interfaces is very crucial.
5)I consider the proliferation of IS-IS very important as well.
6)OSPF-TE and an implementation of incremental Dijkstra would be
interesting as well.
7)multipath-BGP is important.
8) I agree not reinventing the wheel and introducing a standard packet
sniffing facility is a very nice idea. Here I vote for a config option
where that the user can chose between
whatever tools he/she prefers (tethereal, snoop, tcpdump, ...), a simple
command that can set a path and options, and eventually decoyed debug
commands.
9)Multicasting is very important!

As a conclusion, I propose an abstraction layer that e.g. matches
multicast commands we know from the Cisco CLI into configurations
possible with mrouted or the platform PIM-SM implementations, a job that
could be done via vtysh hooks for netstat, arp, ifconfig, etc. There is
still so much work to do within the existing protocol daemons - let's
clean up OSPF and BGP first. Lot of architectural implications I guess :-).

Regards,
Gernot

--
Dipl.-Ing. Gernot W. Schmied, MS Network Architecture & Operations
Senior Strategist Research Group
mailto:gernot.schmied@nanorg.org http://www.nanorg.org
PGP Fingerprint: 5D70 5690 47DA 9A21 D07E B9EE C764 C9B7 9B64 B27E

On Mon, 2003-08-18 at 04:12, Gernot W. Schmied wrote:
> Jean-Francois Laforest wrote:
> > As I said 2 days ago, I would email you with a list of functionality
> > that should be implemented. Give me full feedback.
> >
> > Goals:
> > - QoS control (Linux (HTB, CBQ, etc.), FreeBSD (ALTQ)).
> > - Packet filter control (iptables, pf, ipf)
> > - tcpdump access off vtysh (could be neat)
> > - show device status (errors, etc... could also be route statistics, see
> > netstat -ni (under bsd))
> > - Full MPLS support
> > - ARP functionality (monitoring arp requests, doing changes, acl, etc)
> > - IP accounting functionality
> > - Make vtysh the CLI of choice that can launch/kill/etc. services.
> > - IPsec support.
> > - Tunneling devices (gre, gif, etc.) advanced support (add, remove,
> > modify)
> >
>
> Hi,
>
> Let me somehow question the "everything under one bloated umbrella"
> approach and not get carried away in the very beginning:

This is just ideas I've wrote down.

> 1)Zebra and its protocol daemons are signalling daemons and route
> processors by its very nature. That should remain the "prime directive"
> in Star Trek lingo. I do not advise to shift this focus towards
> integration of unnecessary user-space clutter just to have a bloated
> universal GUI that breaks whenever little changes to GRE or heaven knows
> what are introduced at the cost of platform independence. The CLI should
> never be at the center of our design consideration. I don't think it is
> adwisable to administer everything network related on a UNIX box from
> within Zebra.

I just wanted to know if an IOS style of platform was the direction we
could go forward. I guess it was a too big vision.

> 2)Multiple routing tables are only available for Linux, hence it will
> most likely be the only operating system that will benefit from MPLS
> advanced features. To my knowledge there is no MPLS signaling work in
> progress for BSD. I'd rather like to see multiprotocol BGP evolve then
> isolated MPLS approaches.

*nod*

> 2)Hence for the time being packet filter and IPSec should stay outside
> the Zebra engine. Too complicate protocol suites and too platform
> dependent (pf, ipfilter, ipfw, iptables/netfilter, ...)
> It is safe to assume that the KAME implementation will be the protocol
> suite of choice for almost all relevant Linux/BSD OSs starting from
> Linux 2.5.x with regards to IPsec. That might improve such endeavors.

Indeed

> 3)Let us learn from the way the ip utility under linux evolved. I do
> think that here the folks did a good job of something similar than you
> envision. They succeeded because they bundled *related* stuff together
> but it does not concern signalling. I don't want to see IPsec
> administration in the ip utility. But it should work on all platforms
> and hence include the minimals set of features.

Iproute2 is nice. Well, like I said, I was having a IOS vision.

> 4)Tunnel devices are a nice thing and important feature that shoud go
> into the CLI very soon. In fact, supporting as many interfaces and
> pseudo-interfaces is very crucial.

Does anyone else supports this idea? I do very much.

> 5)I consider the proliferation of IS-IS very important as well.

IS-IS work hasn't been completed or got anywhere near stable if I recall
correctly.

> 6)OSPF-TE and an implementation of incremental Dijkstra would be
> interesting as well.

OSPF-TE is implemented. For incremental dijkstra, yes, it would save a
lot of cpu/memory on heavily loaded routers. A full recalculation of the
routing table(s) for every topology changes made (during updates) is
intensive and will cause stability issues. I urge that we look forward
to implement such.

Note, has BGP MD5 authentication finally been implemented? There was a
patch around for the linux kernel and quagga (zebra also). I've lost
track with it's status.

> 7)multipath-BGP is important.

I would like to test it in my lab at work and at home, if you do have
some code I could look into, please tell me.

> 8) I agree not reinventing the wheel and introducing a standard packet
> sniffing facility is a very nice idea. Here I vote for a config option
> where that the user can chose between
> whatever tools he/she prefers (tethereal, snoop, tcpdump, ...), a simple
> command that can set a path and options, and eventually decoyed debug
> commands.

It would be useful for any network operator to check directly from his
vtysh console if his packets are going out and coming back in
(vice/versa). In other words, testing purposes, but, usually we all have
multiple terminals opened. We need to establish a list of the most
popular sniffing tools around and build sort of a limited support.
tcpdump/ethereal are 2 of the most known sniffers. To really push it, we
could use a little parser to highlight some regexp in the dumps, though,
these features should be considered "advanced" debugging features. Any
ideas?

> 9)Multicasting is very important!

Slightly noticed. :)

> As a conclusion, I propose an abstraction layer that e.g. matches
> multicast commands we know from the Cisco CLI into configurations
> possible with mrouted or the platform PIM-SM implementations, a job that
> could be done via vtysh hooks for netstat, arp, ifconfig, etc. There is
> still so much work to do within the existing protocol daemons - let's
> clean up OSPF and BGP first. Lot of architectural implications I guess :-).

Agreed. If you do have more ideas based on actual architectural changes,
add-ons / any bug fix, you know where to ring. For PIM-SM/DM, there was
Denis Ovsienko that worked on a port based on some old version. I don't
know if he completed to the hooks to zebra and / or if it's running. I
am writing the documentation (I've been for a while, but time is not in
my hands usually), and I do need lots of information from you guys.
Anything that goes through your mind, go through this list or contact me
directly.

Sincerly,
--
--------------------------
| Jean-Francois Laforest |
-------------------------------------------------------------------------------
| http://www.ipv6peer.net | Feel this ATM frame |
| fuzzball@ipv6peer.net | BOFH: What was your user name ? :) |
-------------------------------------------------------------------------------

Jean-Francois Laforest <fuzzball@ipv6peer.net> writes:

| As I said 2 days ago, I would email you with a list of functionality
| that should be implemented. Give me full feedback.
>
| Goals:
| - QoS control (Linux (HTB, CBQ, etc.), FreeBSD (ALTQ)).
| - Packet filter control (iptables, pf, ipf)
| - tcpdump access off vtysh (could be neat)
| - show device status (errors, etc... could also be route statistics, see
| netstat -ni (under bsd))
| - Full MPLS support
| - ARP functionality (monitoring arp requests, doing changes, acl, etc)
| - IP accounting functionality
| - Make vtysh the CLI of choice that can launch/kill/etc. services.
| - IPsec support.
| - Tunneling devices (gre, gif, etc.) advanced support (add, remove,
| modify)

VLan support would also be very nice.

--
Lgb

hi,

My feeling is that most of these are already supported in the operating
systems. I would prefer to see...

- recursive routes. (i know some work has been done recently on this)
- support for multiple routing tables in route-maps
- support for realms in route-maps

These could then interface into htb, iptables, etc.

Paul


On Mon, 2003-08-18 at 11:37, Lars Gullik Bjønnes wrote:
> Jean-Francois Laforest <fuzzball@ipv6peer.net> writes:
>
> | As I said 2 days ago, I would email you with a list of functionality
> | that should be implemented. Give me full feedback.
> >
> | Goals:
> | - QoS control (Linux (HTB, CBQ, etc.), FreeBSD (ALTQ)).
> | - Packet filter control (iptables, pf, ipf)
> | - tcpdump access off vtysh (could be neat)
> | - show device status (errors, etc... could also be route statistics, see
> | netstat -ni (under bsd))
> | - Full MPLS support
> | - ARP functionality (monitoring arp requests, doing changes, acl, etc)
> | - IP accounting functionality
> | - Make vtysh the CLI of choice that can launch/kill/etc. services.
> | - IPsec support.
> | - Tunneling devices (gre, gif, etc.) advanced support (add, remove,
> | modify)
>
> VLan support would also be very nice.

Paul Cammidge <quagga@pccc.co.za> writes:

| hi,
>
| My feeling is that most of these are already supported in the operating
| systems.

Sure but that goes for all the interface handling zebra is doing
already.

An IOS approach would IMHO be pretty nice.
(and then have init just be zebra in the end for a dedicated router. :-)

--
Lgb

Jean-Francois Laforest wrote:
> On Mon, 2003-08-18 at 04:12, Gernot W. Schmied wrote:
>
>>Jean-Francois Laforest wrote:
>>

Hi JF,

>
> I just wanted to know if an IOS style of platform was the direction we
> could go forward. I guess it was a too big vision.
>
IOS parsing approaches are not the holy grail. The big advantage of an
IOS-like CLI and operation is that we can rely on CCO for documentation.
Some approaches on the UNIX shell CLI and tools cannot easily be
converted or seamlessly integrated in such an architecture. I am a lousy
programmer but can certainly be of assistance with the framework and
abstraction layer if you want. I dislike IOS approaches at certain
occasions, e.g. IPsec :-).

>
>
>>5)I consider the proliferation of IS-IS very important as well.
>
>
> IS-IS work hasn't been completed or got anywhere near stable if I recall
> correctly.
>
Well, yes it is just a start, very buggy and not yet there.

>
> Note, has BGP MD5 authentication finally been implemented? There was a
> patch around for the linux kernel and quagga (zebra also). I've lost
> track with it's status.
>

Of course, very important feature. If I recall it right, Kunihiro was
opposing the IETF approach of making this mandatory for BGP, he wanted
to use IPsec for this.

>
> It would be useful for any network operator to check directly from his
> vtysh console if his packets are going out and coming back in
> (vice/versa).

Wrong place, Zebra does not forward!!!!! Maybe extendend ping/traceroute
would be nice.
Please don't misunderstand me. I do not see a lot of benefit in going
through a great deal of work just to mimic IOS in its current state. I'd
rather prefer a revolutionary approach such as the nice add-ons to the
BGP show commands proposed recently. We can always "hide" new approaches
under common command structures. Maybe abstraction layers and
configuration files to the parser would be the best approach,
customizable commands if you want plus syntax highlighting.

In other words, testing purposes, but, usually we all have
> multiple terminals opened. We need to establish a list of the most
> popular sniffing tools around and build sort of a limited support.
> tcpdump/ethereal are 2 of the most known sniffers. To really push it, we
> could use a little parser to highlight some regexp in the dumps, though,
> these features should be considered "advanced" debugging features. Any
> ideas?

Yes, I strongly opt for a colorized version of the parser.

>
>
>>9)Multicasting is very important!
>
>
> Slightly noticed. :)

Forgive my current bias :-)))

>
> Agreed. If you do have more ideas based on actual architectural changes,
> add-ons / any bug fix, you know where to ring. For PIM-SM/DM, there was
> Denis Ovsienko that worked on a port based on some old version. I don't
> know if he completed to the hooks to zebra and / or if it's running. I
> am writing the documentation (I've been for a while, but time is not in
> my hands usually), and I do need lots of information from you guys.
> Anything that goes through your mind, go through this list or contact me
> directly.
>

Best Regards,
Gernot

--
Dipl.-Ing. Gernot W. Schmied, MS Network Architecture & Operations
Senior Strategist Research Group
mailto:gernot.schmied@nanorg.org http://www.nanorg.org
PGP Fingerprint: 5D70 5690 47DA 9A21 D07E B9EE C764 C9B7 9B64 B27E

On Mon, Aug 18, 2003 at 12:23:38PM +0200, Lars Gullik Bjnnes wrote:
> Paul Cammidge <quagga@pccc.co.za> writes:
>
> | My feeling is that most of these are already supported in the operating
> | systems.
>
> Sure but that goes for all the interface handling zebra is doing
> already.
>
> An IOS approach would IMHO be pretty nice.
> (and then have init just be zebra in the end for a dedicated router. :-)

I have in mind a kind-of 'distribution' which contains all these bits
people have mentioned, such as vrrp, maybe dhcpd and so on, Quagga,
and an extended vtysh / zebra daemon to control it all. You'd only log
in to this vtysh, rather than into the Unix box as normal, so you
could really cut down the underlying OS.

I'd also like to try and build this as a single image file for kernel
and fs, built by scripts (in a Debian package or BSD port perhaps) on
a 'real' Linux or BSD box. Upgrading would then be a matter of
upgrading on that box, rebuilding the image, and downloading it to the
router -- from within the vtysh.

This doesn't belong in the core Quagga distribution of course; that
would be massive bloat, but it seems there's some interest in the
'cisco replacement'.

Oh, and from elsewhere in the thread -- tunnels, yes, definitely. I
have this working on BSD, and I'll post the patch once I've added
Linux support.


Chris.

Paul Cammidge wrote:

> My feeling is that most of these are already supported in the operating
> systems.

I agree. Moreover, most of them are either below L3 (which is the main
concern of zebra/quagga, and so I believe it should be kept), or involve
interfacing with external monitoring / filtering / kernel configuration
tools. Is quagga headed at providing an all-around, OS-specific control
tool for switching/forwarding on UNIX-like systems? I'm not sure it's an
appropriate target, or at least it's totally departed from the previous
one... ;->

> I would prefer to see...
>
> - recursive routes. (i know some work has been done recently on this)

Well, it needs to be defined first: we've had some debates on this
issue, mainly on the theoretical and architectural level, and it seems
that the trade-offs involved with a fully-recursive RIB carry almost
no-profit for most users (and that's being gentle with the terms...). On
the other hand, limited recursive routes for EGPs is a must-have, and it
may use some enhancements: proper recursive-ECMP support (done some
preliminary work on that) and auto-computation of dependencies by the
RIB itself, are very nice to have features, IMO.

> - support for multiple routing tables in route-maps

Multiple route tables are a problem, from several directions: first,
they are Linux-specific, so supporting them would probably mean coding
for Linux; second, they are very proprietary by their design, in means
that they are nowhere near providing fully-independant forwarding
contexts; third, syncing with multiple tables is complex, since it takes
tight syncing with kernel rules. In other words, I would leave
multi-context support aside for a while, until Linux and/or BSD
incorporate some standard approach for multi-context forwarding
(something like the Cisco VRF), which is a good basis for further VPN
applications.

> - support for realms in route-maps
>
> These could then interface into htb, iptables, etc.

I don't know what exactly this means, but seems to me like a
Linux-specific feature, isn't it?


What would I see as possible goals for quagga? Got some short- and
longer-term ideas on my mind:

- Solve thread scheduler restrictions having to do with asynchronous
processing: the current synchronous, non-preemptive design of zebra's
scheduler is problematic under certain circumstances, AFAIK: it might
cause dropping of BGP session under heavy processing; it may lead to
socket overflows (netlink, protocol daemons, etc); current zebra/quagga
uses blocking calls (!) as a detour in order to keep FIB-control synced
(e.g. waiting for netlink acks); and so on. Improvement in this area is
prolonged and takes careful consideration.

- Detach VTY from the logic: right now, VTY is in many cases embedded
into the algorithmic functionality (or is it the other way round? ;-> );
however, in many cases zebra/quagga is just an infrastructure for upper
layers, and working through VTY isn't very comfortable nor efficient. I
would aim at a generalized configuration/monitoring API, that will serve
as another abstraction layer below the VTY, and other control methods as
well (SNMP, web, library calls, you name it).

- IMO, protocol conformance and exhaustive performance tests are crucial
for quagga to become anything of a standard implementation; daily use
interoperability tests are good, but they don't cover the full range of
flaws in an implementation wrt the standards.

Gilad

On Mon, 2003-08-18 at 06:42, Gernot W. Schmied wrote:

> >
> > It would be useful for any network operator to check directly from his
> > vtysh console if his packets are going out and coming back in
> > (vice/versa).
>
> Wrong place, Zebra does not forward!!!!! Maybe extendend ping/traceroute
> would be nice.

I am well aware that it's the OS forwarding and it's only a routing
protocol kit. Please bare with me, I'm tired and expressing myself is
becoming hard. It is meant for debugging if things go wrong. You want to
be able to see what goes through and what doesn't (see
tcpdump/ethereal).

> Please don't misunderstand me. I do not see a lot of benefit in going
> through a great deal of work just to mimic IOS in its current state. I'd
> rather prefer a revolutionary approach such as the nice add-ons to the
> BGP show commands proposed recently. We can always "hide" new approaches
> under common command structures. Maybe abstraction layers and
> configuration files to the parser would be the best approach,
> customizable commands if you want plus syntax highlighting.

I am not clear enough here also, I do not wish to mimic IOS, I just want
it's functionality under one software, but that is a way far fetched
idea to integrate in this project.

--
--------------------------
| Jean-Francois Laforest |
-------------------------------------------------------------------------------
| http://www.ipv6peer.net | Feel this ATM frame |
| fuzzball@ipv6peer.net | BOFH: What was your user name ? :) |
-------------------------------------------------------------------------------

James R. Leu wrote:

>
> I think it is safe to translate "Multiple routing tables" into VRFs.

Hi James,

I tend to agree from an architectural point of view, however, I am not
familiar with the implementation details of the Linux policy routing
tables and how generic the stuff really is.

> There is VRF code for FreeBSD (http://www.tel.fer.hr/zec/)
> and Linux (http://linux-vrf.sf.net/)
>
> I wrote a platform independent LSR API and implementation of LDP (RFC3036).
> The code is part of the "MPLS for Linux" project, but the only part of the
> project that is Linux specific is the MPLS forwarding plane. The signaling
> has all been designed to be portable.
>

Neat. Sounds like a good achitecture, haven't had time yet to dig into
it :-). My view of the world is quite simple: As long as we have a clean
implementation of label distribution protocols (which could in fact be
integrated into Zebra because it is just signaling) and multiprotocol
BGP, it should not be a big problem to unite them at a signaling level
for e.g. BGP-MPLS VPNs someday. I just like to see multiprotocol-BGP
unrelated to MPLS, it is very generic. The forwarding issue is the
OS-MPLS forwarder's job entirely.

> There does exist a MPLS forwarding plane for FreeBSD, but it is stale:
>
> http://www-x.antd.nist.gov/nistswitch/
>

I forgot to mention, there in fact is MPLS on BSD, I am not sure about
life on Mars though :-).
Have a look at http://www.ayame.org. Appears pretty active.

Regards,
Gernot

--
Dipl.-Ing. Gernot W. Schmied, MS Network Architecture & Operations
Senior Strategist Research Group
mailto:gernot.schmied@nanorg.org http://www.nanorg.org
PGP Fingerprint: 5D70 5690 47DA 9A21 D07E B9EE C764 C9B7 9B64 B27E

On 17 Aug 2003, Jean-Francois Laforest wrote:

> As I said 2 days ago, I would email you with a list of
> functionality that should be implemented. Give me full feedback.
>
> Goals:

> - QoS control (Linux (HTB, CBQ, etc.), FreeBSD (ALTQ)).

possibly, providing it can be reasonably abstracted.

> - Packet filter control (iptables, pf, ipf)

ditto.

And as above, i think if one implements this and the neccessary
abstraction of all supported platforms, then one ends up
with LCD functionality - is that worth it?

> - tcpdump access off vtysh (could be neat)

could be.

> - show device status (errors, etc... could also be route statistics, see

> netstat -ni (under bsd))

?

> - Full MPLS support

James is working on that. We'll need to see what the kernel people do
wrt mpls.

> - ARP functionality (monitoring arp requests, doing changes, acl, etc)

?

> - IP accounting functionality

hmm..

> - Make vtysh the CLI of choice that can launch/kill/etc. services.

hmmm..

> - IPsec support.

hmmmm...

> - Tunneling devices (gre, gif, etc.) advanced support (add, remove,
> modify)

hmmmm.....

Some of this stuff is in the 'best left to the OS' category really.
It would be murder to try support all these platform specific things.
All zebra^Wquagga really cares about is that an interface is
presented (or not) over which it can speak a routing protocol.

> To-Do:
> - Fix bugs
> - I'm still doing the docu, leave me alone ;)
> - Advanced project management.

- Recursive RIB
- Better user/auth management for vtysh

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
"I think it is true for all _n. I was just playing it safe with _n >= 3
because I couldn't remember the proof."
-- Baker, Pure Math 351a

On 18 Aug 2003, Jean-Francois Laforest wrote:

> For incremental dijkstra, yes, it would save a lot of cpu/memory on
> heavily loaded routers.

I dont think it saves memory really.

> A full recalculation of the routing table(s) for every topology
> changes made (during updates) is intensive and will cause stability
> issues. I urge that we look forward to implement such.


> Note, has BGP MD5 authentication finally been implemented?

Rick Payne has a patch iirc. However, I get the feeling it will never
be accepted into the linux kernel.

> > 7)multipath-BGP is important.
>
> I would like to test it in my lab at work and at home, if you do
> have some code I could look into, please tell me.

BGP is already multipath. Problem is that the zebra RIB does not
support resolving recursive routes (eg BGP routes) to multiple
nexthops. Gilad has a preliminary patch iirc.

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
To make tax forms true they should read "Income Owed Us" and "Incommode You".

On Mon, 18 Aug 2003, Gilad Arnold wrote:

> I agree. Moreover, most of them are either below L3 (which is the
> main concern of zebra/quagga, and so I believe it should be kept),

i agree.

> or involve interfacing with external monitoring / filtering /
> kernel configuration tools. Is quagga headed at providing an
> all-around, OS-specific control tool for switching/forwarding on
> UNIX-like systems? I'm not sure it's an appropriate target, or at
> least it's totally departed from the previous one... ;->

If someone manages to abstract, eg firewalling, cleanly, then why not
- but i think it would be very very hard to do so. Hence i agree with
you.

> On the other hand, limited recursive routes for EGPs is a
> must-have, and it may use some enhancements: proper recursive-ECMP
> support (done some preliminary work on that) and auto-computation
> of dependencies by the RIB itself, are very nice to have features,
> IMO.

agreed.

> Multiple route tables are a problem, from several directions:
> first, they are Linux-specific, so supporting them would probably
> mean coding for Linux;

yes. and really, the practical application of multiple routing tables
is MPLS/VRF - and we still have to wait and see what happens in linux
in this area.

> takes tight syncing with kernel rules. In other words, I would
> leave multi-context support aside for a while, until Linux and/or
> BSD incorporate some standard approach for multi-context forwarding
> (something like the Cisco VRF), which is a good basis for further
> VPN applications.

absolutely.

> I don't know what exactly this means, but seems to me like a
> Linux-specific feature, isn't it?

yep.

Notice a trend here? Lots of stuff is linux specific. Do we ignore
features because they are linux specific? Or do we support them and,
probably, devalue Quagga on other platforms.

> - Solve thread scheduler restrictions having to do with
> asynchronous processing: the current synchronous, non-preemptive
> design of zebra's scheduler is problematic under certain
> circumstances,

yes.

> AFAIK: it might cause dropping of BGP session under heavy
> processing; it may lead to socket overflows (netlink, protocol
> daemons, etc); current zebra/quagga uses blocking calls (!) as a
> detour in order to keep FIB-control synced (e.g. waiting for
> netlink acks); and so on. Improvement in this area is prolonged and
> takes careful consideration.

It does. I'm still waiting for someone to test my work queue patch!
(or even comment on it :( )

> - Detach VTY from the logic: right now, VTY is in many cases
> embedded into the algorithmic functionality (or is it the other way
> round? ;-> ); however, in many cases zebra/quagga is just an
> infrastructure for upper layers, and working through VTY isn't very
> comfortable nor efficient. I would aim at a generalized
> configuration/monitoring API, that will serve as another
> abstraction layer below the VTY, and other control methods as well
> (SNMP, web, library calls, you name it).

yes. I was thinking about this previously wrt to vtysh, and one day
moving vty out of the daemons to vtysh, and abstracting control
would be nice.

> - IMO, protocol conformance and exhaustive performance tests are
> crucial for quagga to become anything of a standard implementation;
> daily use interoperability tests are good, but they don't cover the
> full range of flaws in an implementation wrt the standards.

yep.

> Gilad

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
You scratch my tape, and I'll scratch yours.

> 2)Multiple routing tables are only available for Linux, hence it will
> most likely be the only operating system that will benefit from MPLS
> advanced features. To my knowledge there is no MPLS signaling work in
> progress for BSD. I'd rather like to see multiprotocol BGP evolve then
> isolated MPLS approaches.

I think it is safe to translate "Multiple routing tables" into VRFs.
There is VRF code for FreeBSD (http://www.tel.fer.hr/zec/)
and Linux (http://linux-vrf.sf.net/)

I wrote a platform independent LSR API and implementation of LDP (RFC3036).
The code is part of the "MPLS for Linux" project, but the only part of the
project that is Linux specific is the MPLS forwarding plane. The signaling
has all been designed to be portable.

There does exist a MPLS forwarding plane for FreeBSD, but it is stale:

http://www-x.antd.nist.gov/nistswitch/

--
James R. Leu

----- Original Message -----
From: "James R. Leu" <jleu@mindspring.com>
To: "Gernot W. Schmied" <gernot.schmied@nanorg.org>
Cc: <quagga-dev@lists.quagga.net>
Sent: Monday, August 18, 2003 5:02 PM
Subject: [quagga-dev 180] Re: Goals / To-Do proposal.


> > 2)Multiple routing tables are only available for Linux, hence it will
> > most likely be the only operating system that will benefit from MPLS
> > advanced features. To my knowledge there is no MPLS signaling work in
> > progress for BSD. I'd rather like to see multiprotocol BGP evolve then
> > isolated MPLS approaches.
>
> I think it is safe to translate "Multiple routing tables" into VRFs.
> There is VRF code for FreeBSD (http://www.tel.fer.hr/zec/)
> and Linux (http://linux-vrf.sf.net/)
>


Yon Uriarte did some work to support VRFs in a "portable" way in zebra
that I'm using myself on several routers. His implementation supported linux
routing tables and the linux-vrf patch. Maybe he'll want to comment if he's
still around.

Best regards,

-Jorge

==============================================================
Jorge Boncompte - Tecnico de sistemas
DTI2 - Desarrollo de la Tecnologia de las Comunicaciones
--------------------------------------------------------------
C/ Abogado Enriquez Barrios, 5 14004 CORDOBA (SPAIN)
Tlf: +34 957 761395 / FAX: +34 957 450380
--------------------------------------------------------------
jorge@dti2.net _-_-_-_-_-_-_-_-_-_-_-_-_-_ http://www.dti2.net
==============================================================
- Sin pistachos no hay Rock & Roll...
- Without wicker a basket cannot be done.
==============================================================