Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Jan 2005 11:37:11 -0800
From:      Brooks Davis <brooks@one-eyed-alien.net>
To:        Boris Kovalenko <boris@tagnet.ru>
Cc:        freebsd-net@freebsd.org
Subject:   Re: [PATCH] 802.1p priority (fixed)
Message-ID:  <20050123193711.GB29225@odin.ac.hmc.edu>
In-Reply-To: <41F33E9F.9090301@tagnet.ru>
References:  <41F33E9F.9090301@tagnet.ru>

next in thread | previous in thread | raw e-mail | index | archive | help

--JP+T4n/bALQSJXh8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 23, 2005 at 11:05:19AM +0500, Boris Kovalenko wrote:
> Hello!
>=20
>=20
> >I'm not sure why you need trust and override.  It seems like you only
> >need the ability to set or remove values as well as acting on already
> >attached tags (which we're going to need to carry around as m_tags so >we
> >can filter on and modify them in conjunction with layer 3 information).
>=20
> 	For example I have vlan of devices, which can set 802.1p themself=20
> (Cisco IP Phones for example) based on their knowledge of situation. I=20
> should just pass-trough their 802.1p because I don't know the situation.=
=20
> In this case I should trust. Another example - I have devices that can=20
> not set 802.1p (or more simply - it always 0), so I should set (or in=20
> other words - override received value :) 802.1p myself.

I still don't see how this usefull differs from taking action or not
taking action.

> > 3. Mark 802.1p at vlan drivers like 2
> > ifconfig vlan0
> > 	vlan: 100 802.1p: 6 CFI: 0 mode: trust vlandev: bge0
> > Here we are trusting received from low level information and set 6 if it
> > is omitted
> > ifconfig vlan0
> > 	vlan: 100 802.1p: 6 CFI: 0 mode: override vlandev: bge0
> > Here we silently set 6.
>=20
> >If you're not going to do separate interfaces per priority (or
> >perhaps set of priorities[0]) I'm not sure what the point of having the
> >interface do anything is.  Filtering is the job of the firewall so I'm
> >not convinced we should be doing it in the vlan device.  There's also
>=20
> 	Hmm... If You remember, the idea of filtering is not mine :) I wrote=20
> 	it may be realized, but see no sense in that. The only thing I suggested=
 is=20
> to set 802.1p values. Again, there are working realizations of 802.1p in=
=20
> a world. Cisco for example. I can not access/modify 802.1p in firewall=20
> (PIX/ACL/VACL). The only place where I may set 802.1p is the Catalyst=20
> port. And on trunking port I may trust received values or reset them.=20
> So, may be we should not to invent a bicycle?

What Cisco does is of rather limited relevence IMO.  The default case of
a FreeBSD system is not a bridge or router but a host.  We need to
determine what makes sense for both the bridge/router case and the host
case.  Cisco's are for all practical purposes, not hosts.

> >the complication that we need to handle the vlan=3D0 case which shouldn't
> >be treated as a vlan at all and should be decapsulated in the actual
> >device without a trip through the vlan code.
>=20
> 	What the vlan=3D0 is? On a wire we may receive tagged or untagged=20
> 	frames. Untagged should go usual way, tagged via vlan driver (IMHO).

I've found at least one refrence when googling for 802.1p which says
that vlan 0 is reserved and means that the tag is only a priority.  In
that case there is no vlan and I don't think vlan devices should be
involved.  If they are, you must set the priority on every frame or
priority and non-priority frames will be delivered to different
intefaces which may or may not be what you want.

I'm not 100% sure that's correct, but the IEEE has made it practialy
impossiable to find 802.1p.  I haven't found it yet.

> >My suspicion is that we need to rethink the current separation of
> >ether and vlan code.  Making vlans less optional and doing more of the
> >handling in ether_input and ether_output might be a good thing.
>=20
> 	I'm not a guru of FreeBSD net infrastructure, so I can not raise an=20
> objection on this words.
>=20
> >[0] What I've read says that many switches group sets of priority=20
> >values together reducing the set of valid values.
>=20
> 	And what this changes? Some switches totally ignore 802.1p. We're=20
> talking about IEEE standard and should fully support it. Also, may You=20
> point me where You have read this?

The issue is that you may need the ability to treat some values as
though they are the same because some network environments will do this.

While I think a lower level solution will be the most useful in the
end, I don't object to an interface based solution.  I think you should
proceed with that with the idea that you add a third, optional keyword
to vlan initalization to specify priority.  That way you can create
seperate interfaces for each priority for any vlan tag.  Something like:

ifconfig vlan create vlan 2 vlandev fxp0 vlanpri 3

-- Brooks

--=20
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

--JP+T4n/bALQSJXh8
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFB8/zmXY6L6fI4GtQRAvS4AJ4/z22QZLzjTXstgotJCGf6/pgiHQCgn2AP
t8yv28D5zAsRvfqT4/Hu6Ls=
=pjiu
-----END PGP SIGNATURE-----

--JP+T4n/bALQSJXh8--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050123193711.GB29225>