Paul Ferguson <pferguso(a)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...)
