Subject: Re: why doesn't NetBSD support bridge in kernel?
To: None <>
From: Markus A. Boeing <>
List: tech-net
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, 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 
> features.
> > 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