Santosh Koshy asked,
>With new & emerging technologies like (Gig Eth, 10 Gig Eth, e.t.c), I am
>beggining to wonder how scalable or well suited today's routing protocols
>(OSPF, IGRP, EIGRP, e.tc. ) are to manage them effectively.
I think you are making an inherent assumption that the ability to
have precise metrics is essential to routing protocols. That's less
and less the case. There are, however, limiting factors for
conventional IGPs. My feeling is that they will continue to be
evolved rather than be replaced by new paradigms.
First, bandwidth often is cheap, as in campus or photonic networks.
Fine distinctions aren't that important. Where there is a bandwidth
limitation (e.g., wireless), there's a whole range of relevant
techniques at all OSI layers.
Second, topology, in well designed networks, usually is more
important than metric.
Third, static bandwidth and delay do not reflect utilization, and
(E)IGRP style utilization at the link level don't scale to routes of
any complexity. Traffic engineering extensions to OSPF and ISIS, or
strategies like Optimized Multipath (OSPF-OMP, ISIS-TE) take a more
reasoned view of reservation and utilization.
>
>I stubled across something while reading about delay calculations on a IGRP
>/ EIGRP network... maybe you guys can help..
>
>The bandwith component of a metric is calculated by dividing 10,000,000 by
>bandwith in Kbps.
>Eth = 10,000,000 / 10,000 = 1000
>Fast Eth = 10,000,000 / 100,000 = 100
>Gig Eth = 10,000,000 / 1,000,000 = 10
>10 Gig Eth = 10,000,000 / 10,000,000 = 1
>New Fangled Eth (not yet invented) = 10,000,000 / 100,000,000 = 0.1
>
>As you can see delay will be calculated in thousands of microseconds and we
>end up getting fractional numbers...... I highly doubt IOS can use
>fractional numbers to calulate delay...... Are todays's routers capable of
>making such calculations with an easy IOS upgrade....
In general, my feeling is that we will be more concerned with metrics
as orders of magnitude rather than precise numbers that fit all. Yes,
it's possible to have low-bandwidth radio links and GigE in the same
network, but they are in different parts of the network and would be
optimized locally. For example, I dealt with one military network
where the 2.4 Kbps tactical radio links needed some optimization due
to very low bandwidth, but this optimization needed to take place at
the access tier. Once they were into the fixed network, in
comparison with 2.4 vs. 4.8 Kbps (poor vs. better radio), the 10-1000
Mbps Ethernets were effectively infinite resources.
Now, there are issues, and controversial ones, with convergence time.
Current IGP's typically reconverge in tens of seconds, which is too
slow for certain services such as voice call setup. In other
services, nothing is broken. A good summary of some issues in
speeding IGP convergence, specifically for ISIS but generally
applicable, is http://www.nanog.org/mtg-0010/igp.html
Fast response to convergence may be OK in an IGP, but, in the context
of the global Internet, may contribute to instability. There is much
controversy and theoretical work going on in global BGP convergence.
See http://www.nanog.org/mtg-0010/labovitz.html. Some of the
complexities being explored in the research community deal variously
with BGP's path vector algorithm itself, with the issue of
constraint-based BGP routing (path vector can be guaranteed to
converge only when additional constraints, such as AS path length and
MED, are not considered), and operational use of constraints and
policies.
Single router BGP convergence is a related but different problem I'm
working on defining, see my rough draft at
http://www.ietf.org/internet-drafts/draft-berkowitz-bgpcon-00.txt.
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]