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

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

catching up...


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?
I tend to agree with Tony here that routing table size and churn are two separable issues. The former is a scaling issue; the latter is more of a protocol/implementation issue---one can have bad churn even with a small routing table size.
As the Internet gets bigger, the churn does go up, but it may have more to do with the scalability of cluefulness than the table size, though both are the result of getting big. 



   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.
Personal opinion: yes the existing statement can benefit from further quantification, though I feel less sure how much improvement the suggested alternative brings...
Splitting prefixes is a simple and effective means to achieve traffic engineering goals, and whoever needs to do it will do it. I believe a scalable solution essentially lies on the ability to effectively (re) aggregate prefixes. 



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?
if the above paragraph is the only place where "Attachment point" and "location" are used interchangeably, it seems to me that a simple solution is to change the last sentence to 
     Therefore,
     it is desired that a solution separate the host attachment
     point namespace from the identification namespace.



   "Stretch"

Optimality ratio?

Also, how about something about "with the queuing treatment
requested"?


I am not sure what this meant...



   Convergence

You mention convergence but can we be more specific about what are we
after?  Convergence time that scales with log n?  ??
this comment raised a good point: there are probably a few open issues embedded herein 
- in literature there are schemes that can converge in constant step
(for example, "BGP-RCN: Improving BGPConvergence through Root Cause Notification" 
  http://www.research.att.com/~peidan/bgp-rcn.pdf)
- but there is a cost associated with such solutions.
So convergence speed cannot be a goal on its own, one has to consider the cost. 
- Tony's reply hits an important issue: convergence itself is not the
  ultimate goal, data delivery is.
  If data can be successfully delivered *during* convergence,
  then a stringent limit on convergence delay may not be necessary?

if anyone is interested in literature along this line, see
* "A Study of Packet Delivery Performance during Routing Convergence"
IEEE DSN 2002, http://www.research.att.com/~peidan/peid_packet.pdf
* "A Measurement Study on the Impact of Routing Events on End-to-End Internet Path Performance" 
SIGCOMM 2006, http://www.eecs.umich.edu/~zmao/Papers/mhBeacon.pdf
* "Achieving Convergence-Free Routing using Failure-Carrying Packets"
to appear in SIGCOMM 2007
http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-28.html

Lixia

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