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

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


Hi Scott,
Thanks for your comments. Please see inline. I think a number of these questions should spark discussions. 



   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?
As I think we've discussed before, it's my personal contention based on my BGP experience that the churn is actually an artifact of the protocol and is not fundamental to the current routing architecture. I believe that the churn can be adequately addressed by some additional implementation sophistication within BGP, and I'm actively and personally working on this topic, albeit at a greatly restricted bandwidth. Folks interested should stay in touch with the IDR mailing list or drop me a line.
That said, I do feel that this document should reflect the rough consensus of the research group. If folks feel that I'm grossly misrepresenting the group, please step up and debate your point. 



   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.
I like the finesse, but sooner or later, we're going to have to give a definition for 'traffic engineering'. It's simply too common a term for us to duck. Also, the current inter-domain TE approach really doesn't require anything more than the destination address. It's just providing much more granularity than mere reachability would require. We also already have policy considerations in path computation via BGP today.
I'm more than happy to improve the definition if you have specific suggestions, but on my own, I'm failing to come up with something that's satisfactory without referring to 'normal' or 'current' routing. 



   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?
Happy to do so, but we should provide a clear definition of each. Care to propose text? 



   "Stretch"

Optimality ratio?
Thanks, but 'stretch' already seems to be the accepted term in the literature. 



Also, how about something about "with the queuing treatment
requested"?
Do we have consensus that this should be a goal? It's the first time I've seen it raised in this forum. In any case, please propose text. 



   Convergence

You mention convergence but can we be more specific about what are we
after?  Convergence time that scales with log n?  ??
Well, my personal preference would be convergence that prevents my TCP connections from breaking. Do folks have other metrics that they'd like to propose? I know some folks will simply say 50ms. 

Tony

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