Subject: Re: why doesn't NetBSD support bridge in kernel?
To: Markus A. Boeing <markus@boeing-online.de>
From: None <ww@hagbard.groovy.net>
List: tech-net
Date: 07/06/2001 13:15:52
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
though). 

> 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
following:

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
appropriate. 

-w