Subject: Re: PF for netbsd
To: None <avalon@caligula.anu.edu.au>
From: Kenjiro Cho <kjc@csl.sony.co.jp>
List: tech-net
Date: 06/27/2003 21:21:08
Darren,

> Some questions for KAME people...
> 
> Do you have an official interface description for how other providers
> of packet classification can integrate with ALTQ or do we need to
> RTFS ?

[snip several questions on API]

> Kenjiro, if you are serious about external packet filters for KAME's
> IPSec then shouldn't this be the logical next step in ALTQ's evolution ?
> (At present I notice hard coded references to pf...)
> 
> If ALTQ is going in that direction anyway, maybe we should just wait
> until the ALTQ API is decided upon and finalised for general use before
> integrating the new version of ALTQ into NetBSD.  Fewer changes and
> less pain for NetBSD users in general.

My impression is that API is not so important here.

When tagging is used,  we have 2 approaches.
independent-model:
	a tagger (packet filter) and a consumer (altq, ipsec, etc)
	are independent, and configured independently.
unified-model:
	a tagger and a consumer are unified and configured by a single
	config file.

Currently, setkey(8) is the independent model and ALTQ is
the unified model but both can be implemented either way.

The independent model is too simple to be an API.
The tagger and the consumer share only tag values.  All you need is a
mechanism to map a string label to the corresponding tag value.
In pf, pf creates and keeps mapping, and provides a function to
retrieve tag values.
	u_int16_t pf_tagname2tag(char *tagname);
So, if IPFilter provides a similar function, we can make use of
IPFilter.

The unified model is too complex to be an API.
Different packet filters have different config syntax and different 
semantics of attach/detach/enable/disable filter rules.
So, while working on pf, I realized that it is more practical to
write a queue model which fits the existing packet filter model, and
then, add necessary glues for ALTQ.

That's my impression at the moment, though others may have different
ones.

> And just in case anyone is wondering, I don't think those behind
> ALTQ ever asked or approached me about collaboration (or at least
> I don't recall any such email conversation.)  The reason behind
> ALTQ/pf collaboration is...well...I'm sure NetBSD'ers will have
> their own suspicions without me saying anything.

There's no conspiracy behind it.  It's just because I didn't have a
chance to drink beer with you :)

-Kenjiro