Date: Mon, 16 Apr 2007 09:07:55 +0200 (CEST) From: Lars Erik Gullerud <lerik@nolink.net> To: Shteryana Shopova <syrinx@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: CFT: new trunk(4) Message-ID: <20070416085609.G442@electra.nolink.net> In-Reply-To: <61b573980704150428u5e376d60k6fbe66409493c3bb@mail.gmail.com> References: <peterjeremy@optushome.com.au> <20070411191450.GE815@turion.vk2pj.dyndns.org> <E1Hbs1M-000FWA-7Z@clue.co.za> <20070412210957.GA31864@heff.fud.org.nz> <461FB498.4030407@freebsd.org> <61b573980704150428u5e376d60k6fbe66409493c3bb@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 15 Apr 2007, Shteryana Shopova wrote: > LACP == Link Aggregation Control Protocol - dynamic trunking - one of > the modes trunk(4) supports. And it's Cisco vs the rest of the world > where Cisco calls a trunk multiple VLANs over single physical > interface and the rest of the world calls a trunk multiple physical > interafces bundled together. We don't have to necessarily agree with > Cisco. Please keep the current name. I beg to differ. The terms "trunk" and "trunk-style link" are used throughout IEEE 802.1Q-2005 in examples and illustrations to demonstrate the concept of carrying multiple tagged vlans over a single link, as opposed to an "access-style link" carrying a single untagged vlan. (802 standards that are more than 12 months old are available for free download at http://standards.ieee.org/getieee802/ ) As for "the rest of the world": In the telecoms industry, the term "trunk" is also generally used to indicate one datalink carrying multiple signal streams, an example would be an E1 link carrying n * 64kbit voice channels. In the carrier ethernet/metro ethernet space, the term "trunk" is also generally used in what you would call "cisco-style". Most equipment vendors do also agree with cisco there, with Extreme being one of the notable vendors on the other side. (Alcatel, Riverstone etc. uses trunk in the vlan trunk sense). However in the end, whether Cisco or Extreme are in the right, is really not that interesting. The point is really that the name IS used for different features, and that it therefore IS confusing for users. So why not just give it a name that is more indicative of what the feature actually does? While the OpenBSD guys have given us a lot of great stuff, the name "trunk" for this interface is not among them (although the interface itself is!). I'd tend to prefer bond(4) so Linux users will feel familiar, although aggr(4) would be equally good. /leg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070416085609.G442>