By aiming for a solution which eliminates the scalability problem we
would get multiple improvements which you address:
no convergence time problem, no routing churn, a relaxed situation wrt
prefix building pressure, no pressure for loc/id-split from the
scalability problem's point of view (loc/id-split may have other
advantages, e.g. like pointing to the right direction of
research) - and more.
Being of the right size: a thousand times bigger worm needs a lung rather
than taking in oxygen by the skin.
Bestowed with a lung there are even more advantages: You don't have
to expose all your skin both to the air (oxygen) AND the coldness in
winter :-)
Heiner
In einer eMail vom 25.05.2007 01:50:11 Westeuropäische Normalzeit
schreibt swb@employees.org:
Hi
Tony. Some late comments, for your next version. Your text
is
indented.
Long experience with inter-domain
routing has shown us that the
global BGP routing table is
continuing to grow rapidly [BGPGrowth].
Carrying this large
amount of state in the routing plane is
expensive and places
undue cost burdens on network participants
that do not
necessarily get value from the increases in the routing
table size. Thus, the first required goal is to
provide
significant improvement to the scalability of the
routing plane.
The last sentence is a fine end result, but carrying
the state
information isn't the only problem. What about
churn?
Traffic engineering is the capability of
directing traffic along
paths other than those that would be
computed by normal IGP/EGP
routing. Inter-domain
traffic engineering today is frequently
accomplished by
injecting more-specific prefixes into the global
routing
table, which results in a negative impact on routing
scalability. A scalable solution for inter-domain
traffic
engineering is strongly desired.
Again I like
the last sentence but not the lead-in. If we are
defining new
routing capabilities, what is "normal"? Current? How
about
deleting the first sentence and revising the last as:
A scalable solution for directing traffic along
inter-domain
paths according to more than just
destination address is strongly
desired.
Onward ...
Numerous sources have noted
that an IPv4 address embodies both host
attachment point
information and identification information. This
overloading has caused numerous semantic collisions that
have
limited the flexibility of the Internet
architecture. Therefore,
it is desired that a solution
separate the host location
information namespace from the
identification namespace.
"Attachment point" and "location" are used
interchangeably. They can
be derived from each other 1:1 but I
suspect a location is one way to
name an attachment point, so let's not
use them interchangeably. Do
we need to say somewhere that
locations refer to attachment points?
"Stretch"
Optimality ratio?
Also, how about something about
"with the queuing treatment
requested"?
Convergence
You mention convergence but can we be more specific about
what are we
after? Convergence time that scales with log n?
??
On 04/25/2007 14:48 PM, Tony Li allegedly wrote:
> Hi
Sriram,
>
> Thanks very much for your
suggestions.
>
>> In Section 3.8:
>>
>> My
suggestion in Section 3.8 is to replace the top two paragraphs
>>
with the following four, which are inclusive of the content of
>>
original paragraphs:
>>
>> The routing subsystem is
responsible for computing a path from any
>> point on the Internet
to any other point in the Internet. The
>> quality of the routes
that are computed can be measured by a number
>> of metrics. A
comprehensive list of performance matrices and
>> evaluation
scenarios is needed and can be perhaps fully addressed
>> in a
companion I-D or annex to this document.
>
> Well, I'm not yet
convinced that that level of detail is necessary
> or
beneficial. Our goal is to recommend a routing and addressing
>
architecture, but selecting specific mechanisms is out of scope.
>
Getting to comprehensive, quantitative metrics is going to be very
>
hard without dealing in mechanisms and our goals really should be
>
focused on architectural issues.
We want some general parameters by
which to judge a system, but we
don't know what they are yet. Maybe
we can get closer in the concepts
draft.
swb
--
to
unsubscribe send a message to rrg-request@psg.com with the
word
'unsubscribe' in a single line as the message text body.
archive:
<http://psg.com/lists/rrg/> &
ftp://psg.com/pub/lists/rrg