Subject: Re: why doesn't NetBSD support bridge in kernel?
To: None <email@example.com>
From: Markus A. Boeing <firstname.lastname@example.org>
Date: 07/06/2001 20:07:17
Ok, you presented a valid application for a bridging design solving a
pretty obscure problem. Your point is that there are some valid uses for
bridging and I entirely agree. I never stated that routing is always a
better approach but in most cases it is.
I don't want to start a war regarding Juniper on this list. CCC is a
proprietary solution, perfect time to market, and pretty bad scalability
properties. Well, I'll better stop it now.
At 19:15 06.07.2001, email@example.com wrote:
>On Fri, Jul 06, 2001 at 11:26:41AM +0200, Markus A. Boeing wrote:
> > Well, my statement regarding the merits of routing wasn't out of
> context as
> > your answer implies. I was talking about network size and network
> > Bridging may have its (limited) value in small networks (and only if you
> > don't need redundant links with decent convergence time within your
> > topology etc.).
> > Your example of provider interconnect is a pretty weak one.
> > The technology to interconnect provider networks is "exterior routing
> > protocol" (BGP4) and not bridging!
>I agree that BGP is not bridging. For the purposes of ISP
>interconnect, again I agree BGP is the correct way to do it. However
>my example was of an ISP and some other carrier that they might use to
>reach customers (likely within a city). You can lease fibre, you can
>buy DS1s, DS3s, you can buy ATM PVCs, or in some places you can buy
>tagged VLANs. Although it's not very common yet, you can also get an
>MPLS LSP sometimes, which is really the right way to do it.
> > Bridging between VLANs is not an extremely clever thing to do
> > because it breaks the idea behind the invention of VLANs (control
> > broadcast radiation). If you have to connect VLANs you shouldn't use
> > bridging because that connects broadcast domains.
>Depends on the topology that you make:
> ISP | Transport Provider | customer
>+-----------+ +--------+ +-----------+ +----------+
>| L3 Switch |----| NetBSD |-----| L2 switch |-- ... --| customer |
>+-----------+ +--------+ +-----------+ | router |
>There is nothing particularly significant about connecting broadcast
>domains in this instance: there are only two devices speaking IP as a
>member of a particular VLAN -- the L3 switch and the customer
>router. A tagged vlan becomes functionally identical to an ATM PVC in
>this instance. (Yes I know that most ethernet switch vendors support a
>proprietary mechanism where they can push second tag on packets and
>tunnel tagged traffic the same way you would with MPLS label
>stacking. Some of the L2 carriers that I deal with won't do this
> > If you use routing instead you not only keep the broadcast domains
> > separate but you gain the possibility to control/police your traffic
> > as well. If you're connecting service providers over VLANs, I bet
> > that you would have to implement some sort of policy as well. Which
> > leads us to BGP4 but not to a bridging solution.
>Yes, but the other carrier doesn't do IP at all. They are strictly a
>transport layer provider. And end users are on the other side of them.
> > I've designed quite some large-scale ISP networks, and I've used
> > bridging (L2 switching) only to construct POP interconnects.
> > Building resilient POP interconnects involves redundant
> > bridges/switches, and the use of IP subnets per switched LAN but not
> > fiddling around with VLAN tags (BTW you don't mix up MPLS(label) and
> > VLAN(tag)?).
>Yes. I am trying to make VLAN tags functionally equivalent to MPLS
>labels. The problem with MPLS is it is still not widely supported by
>the vendors or the free OSs.
>And BTW you can do this on Juniper routers using what they call CCC
>(Circuit Cross Connect), and we have tested it and it works quite
>well. Their implementation is general enough to let you do any of the
>vlan - vlan
>pvc - pvc
>lsp - lsp
>vlan - lsp - vlan
>pvc - lsp - pvc
> > Interconnecting other providers always involves BGP, probably on top of a
> > switched LAN, but not bridging.
>My point is only that there are still some valid uses for bridging. I
>agree with you that it should not be used where it is
>inappropriate. But there /are indeed/ instances where it is