Value of telephone numbers

[Paul Ferguson]

Since this thread is deviating from the gist of the initial
discussion, I'll keep this brief.

I would point out that what you are advocation is already
recognized, at least insofar as BGP does not take into
account path congestion, latency, other metrics, etc.

Take at look at:

 http://www.ietf.org/html.charters/qosr-charter.html

We have our first WG meeting in Munich/IETF in August,
and there has been significant discussion on the mailing
list.

In any event, this discussion should be moved to the
QoSR mailing list.

- paul


At 09:32 AM 06/30/97 -0500, Karl Denninger wrote:

>	
>	BGP *sucks* as a means to determine available bandwidth and proper
>	routing configuration.  In fact, BGP does really only one thing 
>	well - determining how many ASNs you must traverse to reach a
>	destination.  Unfortunately, since there is *NO* standardization 
>	of metrics and performance levels associated with them, using BGP 
>	to determine *routing* (rather than reachability) leads to a host 
>	of performance problems.  This cannot be fixed within the *current* 
>	operational parameters of BGP4.  However, it NEEDS to be fixed, 
>	and that probably means that we're overdue for either another
>	version of BGP or something entirely different.
>
>	What a *routing* protocol needs to be able to do is determine the
>	*best* path to a given destination given the potential paths to
>	select from.  "BEST" means, at least to me: 1) least congested
>	and possibly 2) lowest latency.  (2) actually implies (1) most 
>	of the time, but in some cases it might not.
>
>	And yes, I understand that this is a tricky computation, and yes, I
>	also understand that at present it doesn't appear that anyone has
>	done the work required to even *quantify* this problem, say much
>	less attempt to resolve it.
>
>	But BGP doesn't take EITHER of those two items into account in 
>	making its routing decisions, and that's a real issue.
>