layer 2 vs. layer 3
tis like comparing a motorcyle to an automobile--both get you places
but in fairly different ways
rob
I shouldn't be contributing to this thread, but what the hell.
Its not really Layer 2 vs. Layer 3, its how to integrate the
two layers and make it work. Mike O'Dell is fond of saying,
"Pure Layer 3 routed networks are dead," and I can understand
his point, although I don't necessarily agree with it. I do
understand, and I think its important for everyone else
to understand the point here.
Yes, they both get you there, but the pertinent summary to be
drawn from this comparison is that 'you' are the IP packet,
and you really don't care what the mode of transport is (e.g.
frame-relay, leased point-to-point lines, ATM). Each provide
a pipe. Some have more intrinsic flexibility than others (e.g.
virtual circuits) and therefore represent a significant reason
to employ a specific technology over another, given pricing, and
geographic availability.
Again, IP packets don't really care if it's a motorcycle, an
airplane, or an automobile (unless its a Harley :-).
It should also be noted that some technologies, such as
frame-relay are used only in *topologically significant*
places, ie. customer aggregation, for precisely these
reasons. In some networks, frame-relay is used for
customer aggregation, fast-ethernet is used in the PoP,
and ATM is used in the wide-area (just an example).
- paul
Kind of a weird one in a way given that FR has internally its own Layer
2 as well as [stripped down] Layer 3 ... not unlike the [very short]
time when ARAPANET was routed over X.25 many moons ago. Lots of
overhead by this funny layer 2 (error correction, flow control the
work). On the other head, if it works .....
One thing I am curious about .... does anyone actually uses SVC with FR
for use as an underlying network for IP transport? If so, I am curious
as to the pros/cons especially with respect to connection establishment
/ tear down overhead.
Regards,
John Leong
This is not exactly true. Frame Relay -- if designed properly, and with
good frame switches -- can be - IMHO - 10's of times better.
Frame Relay allows yout he ability to psuedo-directly connection various
pop's together, and gives that clean appearance of a 'no-hop' back bone.
Why route when you can switch?
Paul Ferguson <pferguso@cisco.com> writes:
Its not really Layer 2 vs. Layer 3, its how to integrate the
two layers and make it work. Mike O'Dell is fond of saying,
"Pure Layer 3 routed networks are dead,"
So does this mean that Falternet is dead?
Hmmm. Wait, it's not a pure layer 3 network.
Go figure.
and I can understand his point, although I don't
necessarily agree with it.
The point is not so much to use one or the other or to
integrate the two as much as it is to duplicate some of
the handy functionality in PVC-using L2 protocols.
This is something cisco has been doing (bravo), what with
generic rate-limiting, better flow diagnostics and
monitoring, and the like. In current and newer products
from cisco and others, I expect to see some buffer
management strategies that will eliminate the need for the
fancy stuff one finds in FR and ATM and the like.
If one has decent IP routers, one can essentially build on
an L2 structure no more complicated than point-to-point
PPP or HDLC talking circuits, modulo what one does wrt
stuffing an add/drop MUX of some nature into the router
itself.
This tends to avoid the need to do horribly botched and
sometimes proprietary redesigns of L3 routing protocols
such as IS-IS, and lessens the need to do particularly
ugly things with BGP, as one sees in L3 networks layered
on top of NBMA L2 protocols.
In turn, one should expect better stability from such
networks over time.
Trying to integrate "foreign" internetworking technologies
in the manner done by UUNET (whether or not this is Mike
O'Dell's grand design or merely a step in that direction I
honestly don't know) leads to all sorts of interesting trouble.
Yes, they both get you there, but the pertinent summary to be
drawn from this comparison is that 'you' are the IP packet,
and you really don't care what the mode of transport is (e.g.
frame-relay, leased point-to-point lines, ATM).
Actually you do care when you're carrying TCP segments;
for instance, if your L2 network is too clever and messes
up TCP's expectation that you see packets delayed and
dropped when you send too quickly, like say with ABR when
you end up seeing a VS dropping cells (or cell trains or
whatever interesting stuff the ATM people have come up
with to try to un-break ATM's anti-TCP behaviours) because
it hasn't seen an RM come back across an uncongested
network -- similar ugly things happen with FR congestion
management schemes -- you can get really abysmal TCP
performance. Moreover, management of disconnectivity
under separate control loops is suboptimal; if you heal
partitions at the L2 level you get ugly congestion
invisible to traditional L3 routing protocols, and if you
heal at the L3 level, then there seems to be alot of
wasted effort in nailing up lots of VCs in the first place.
Some have more intrinsic flexibility than others (e.g.
virtual circuits) and therefore represent a significant reason
to employ a specific technology over another, given pricing, and
geographic availability.
I will buy the pricing issue. If it werent that Telco N
is offering ATM at OC-3-ish rates for about a fifth the
price of a 155Mbps SONET tributary, and a notorious
equipment vendor making it expensive in terms of equipment
to build a point-to-point network with adequate buffering,
I would expect ATM would be much less popular in several
ATM-using internetworks.
Again, IP packets don't really care if it's a motorcycle, an
airplane, or an automobile (unless its a Harley :-).
IP doesn't like it when SAR messes up or when cells get
dropped in the middle of frames. TCP doesn't like it when
IP gets confused and it also doesn't like it when
non-ATM-forum workarounds for that set of problems allows
one to confront the problems of conflicting
congestion-control vs. congestion-avoidance systems.
Admittedly none of those are inherent in VC-using L2
fabrics, however, most of the deployment rationalizations
I've run into wrt that kind of thing involve congestion
management, QoS, better monitoring and various other
unfulfilled promises that could well find their way into
IP routers Real Soon Now, assuming they aren't there
already.
I will, however, buy the argument that
equipment-unavailable or equipment-unworkable exigencies
drove the deployment of things like ATM and FR, and that
the deployment was useful to push various equipment
vendors into building what would have made the ATM and FR
deployments unnecessary in the first place.
In other words, hey, vendor, I have a gun to my forehead.
It seems less painful right now than what will happen if
we don't get the things we need from you. Give me what I
want or I'll shoot. *Bang*.
It should also be noted that some technologies, such as
frame-relay are used only in *topologically significant*
places, ie. customer aggregation, for precisely these
reasons. In some networks, frame-relay is used for
customer aggregation, fast-ethernet is used in the PoP,
and ATM is used in the wide-area (just an example).
And in some networks DS3s carry aggregated clear-channel
DS1s and fractional DS1s into customer aggregation boxes,
the DS3s for those and for the customers come right out of
SONET ADMs, and 155Mbps POSIP (soon to be faster) is used
essentially everywhere else. Or so goes the plans...
Which networks are having the problems today? 
Sean. (who thinks self-inflicted gunshot wounds
can be self-healed, too, when there is no
longer any economic need to wander around bleeding...)
And of course, I tend to oversimplify the problem
description. 
- paul
Alex Rubenstein <alex@nac.net> writes:
Frame Relay allows yout he ability to psuedo-directly connection various
pop's together, and gives that clean appearance of a 'no-hop' back bone.
Why route when you can switch?
Please explain this last line to me.
Consider a flat network, where each router has a
connection (virtual or otherwise) to every other router in
the network.
An IP datagram arrives at one of the routers.
What happens now?
A clumsy tech or a backhoe takes out a physical path
between two POPs, each of which contains several routers
that form part of this flat network.
What happens now?
A bug partitions the FR fabric, making a few VCs go away.
What happens now?
A new route is announced to one of the routers in the flat
network.
What happens now? (You may wish to consider it both as a
route carried in some sort of IGP and a route learned from
eBGP)
Now unflatten the network so there is a maximally
hierarchical network (the opposite of a flat network),
in which only routers topologically adjacent to each other
have any form of circuit-like connectivity. Go back and
walk through my list of questions, paying particular
attention to the issues involved in changes in IP reachability.
Now, for even more fun, consider variances in delay thanks
to the speed of light in copper & fibre. Consider what
happens when IP reachability changes as traffic is being
sent towards the changing destination(s).
Finally, pretend you work for a large network that combines FR
switches and routers and which is taking it in the shorts
for some reason, and fix the problem so that I can get
from home to cesium.clock.org without frequent long pauses.
Sean. (hi Noel)
Ummm.. Maybe you are missing my point. Those of us that do not have
bottomless pockets to pay for a "EVERY ROUTET HAS A CONNECTION TO EVERY
OTHER ROUTER (VIA PPP -- added by me).
I never said it was the catch all / fix all. But, it is cheaper, and n our
environment, works well and affordably. Backhoes can only do so much
damage, and that is why one has backup ISDN or some other means. In a high
scale network (like BlueBlue Net), they have several DS3 Frame Relay
trunks leaving each PoP, so that dismisses the backhow bit also.
Alex Rubenstein <alex@nac.net> writes:
Ummm.. Maybe you are missing my point. Those of us that do not have
bottomless pockets to pay for a "EVERY ROUTET HAS A CONNECTION TO EVERY
OTHER ROUTER (VIA PPP -- added by me).
Hmmm... a router that is connected to every other router
via PPP has precisely the same problems as a router
connected to every other router by PVCs using some kind of
CBR-like service.
If I had bottomless pockets I would still design a
maximally hierarchical network. Some routers would be
connected to long-haul point-to-point circuits. Other
routers would talk either via some sort of LAN thing or
if money were no object, probably via POSIP.
The idea would be to create a tree-like fan-out from the
"backbone" routers (the ones with the long-haul circuits)
to the "customer aggregation" routers, aggregating traffic
and reachability information upwards from many customers
towards a set of crunchy boxes with relatively few (but
very fat) interfaces.
The idea is to conserve the amount of work any given
router has to do with respect to convergence, since that's
a poorly-scalable hot-spot.
In the past the hot-spot may have been the amount of
traffic through a box, such that so few fat interfaces
could be used that it was economically compelling to move
that particular load into some sort of L2 switch and take
the lumps wrt inherent routing scalability problems and
the lack of conservation of configuration effort.
Since there are existence proofs that this hot spot is now
no longer economically insurmountable, and some much
crunchier boxes are on the near horizon, the argument for
using smart L2 fabrics at all is becoming weaker.
I never said it was the catch all / fix all. But, it is cheaper, and n our
environment, works well and affordably. Backhoes can only do so much
damage, and that is why one has backup ISDN or some
other means.
ISDN does a lousy job of backing up 140Mbps worth of
traffic...
However, as I said in another message, I buy the argument
that tariffs and vendor pricing (particularly cost/port
for low-speed interfaces, modulo things like the CT-3
card) make fast-packet L2 fabrics attractive.
What I don't understand is the "why route when you can
switch?" assertion, and I'd love someone to explain it to
me in simple terms.
In a high scale network (like BlueBlue Net), they have
several DS3 Frame Relay trunks leaving each PoP, so that
dismisses the backhow bit also.
Something has to do the converging when the underlying
physical topology changes, no?
Sean. (out-of-touch former network hack)
- --
Sean Doran <smd@ab.use.net>
"Boy, you obviously don't have a clue!" -- Chad Skidmore, Datasource L.L.C.
This is not exactly true. Frame Relay -- if designed properly, and with
good frame switches -- can be - IMHO - 10's of times better.
How? Does good frame relay switches accelerate photons or something?
Frame Relay allows yout he ability to psuedo-directly connection various
pop's together, and gives that clean appearance of a 'no-hop' back bone.
Why route when you can switch?
Yes, both frame relay and ATM give the "appearance" of a 'no-hop' backbone.
Just because traceroute doesn't show the switch hop in the middle doesn't mean
that they aren't there.
So what is inherently better about that, unless you are into marketing
vapours?
I can see the argument that with current generation of rather deficient
routers, switches have smaller per-hop latency, but even this is pretty silly
since that difference is a noise lost in the cross continental/cross oceanic
propagation delay.
This should be a moot point any way with the impending introduction of real
routers in to the networks.
-dorian
That all depends on whether the wounds are treated like badges of honour or
like wounds.
-dorian
Sean,
We're involved in a discussion on pagan@apnic.net about whether the
Internet can afford to have a bunch of small multi-homed ISPs connected to
the net with PI /19s.
IMHO, there is not adequate participation by folks of your level of expertise.
Would you join the discussion please? While I suspect you are subscribed
to the list, I'll be glad to forward recent posts if you so desire.
I appreciate your consideration of the matter and your time.
Thanks,
Larry