[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Re: Comments on the Design Goals I-D



 Scott,
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