Re: [Int-area] New Version Notification for draft-li-int-aggregation-00.txt

[Tony Li <[e-mail]>]

Hi Toerless,

> 1. Is there any specific reason to bring this up now, e.g.: urgency to
> avoid running out of headroom or the like ? Would be good to add that
> to the text for motivation. right now it reads very architectural.


Yes. My hair is turning gray. AFAICT, this is not written down elsewhere. If not published, the concept of an abstraction action boundary might be lost. Noel, who deserves 100% of the credit for this has already passed the point of caring.


> 2. There is no distinction made whether/how the scalability issue
> affects the routing system differently from the forwarding system.
> But i think if we want to step back and take a look at the overal
> solution landscape, then it is necessary to make that distinction.
> 
> Aka: In one possible universe (where less-stupid router vendors finally
> start putting powerful enough control plane CPU/memory into routers),
> i may not predominantly have a scalability issue of the routing subsystem,
> but only of the forwarding subsystem (hardware forwarding entries).


I’ll try not to be offended. But I’m failing.

Router vendors already put in very high end CPUs and gobs of memory. And it’s never enough. The routing table continues to grow open loop. And carriers complain about the costs of the extra memory.


> In this
> universe i could solve the problem through a combination of two
> mechanisms alone:
> 
> a) goegraphical aggregateable allocation of address space by registries


As pointed out, this is already happening.


> b) auto-aggregation within routers from routing-plane to forwarding
>   plane. Aka: Just don't populate the poor HW tables with all those
>   non-aggregated prefixes, but calculate the minimum number of
>   sufficient shorter prefixes.


And some of this is happening, but it is NOT a friendly and rational response to the problem. It has numerous setbacks. Oh, look, a non-aggregatable more-specific showed up. Now I need to expand some of my aggregates. And guess what: it only achieves so much. There are still customers who run out of resources even with this enabled.

Actually doing the aggregation in the control plane is far preferable: it reduces processing and memory requirements for all upstream systems.


> 3. In general, i would suggest to split the asks between that
> geographical aggregateable allocation and the technologies that
> could then potentially benefit from it. Because: I think we want
> the ask for better aggregateable addressing to be pushed into
> the registries faster and independent from the individual technical
> measures operators will employ to benefit from them. E.g.
> 
> - aggregateable addresses first
> - auto-aggregation maybe as first optimization vendors could
>  deliver, creating minimal operational overhead to operators
> - actual aggregation configuration on edge-routers for 
>  the control plane whenever/wherever operators can be persuaded
>  to do this.


The first two are not asks. They are already complete.  The ask is thus the last point.


> 4. It would be great to have a research group in IRTF around addressing,
> for various reasons, but in this case of course specifically to have
> a community of researchers where one might raise the ask to do more
> numerical analysis of possible benefits. Aka: Any of the possible
> points going forward (except with the forwarding-plane auto-aggregation
> maybe) creates significant operational work for registries / operators,
> so there should be sume hard number evidence of how much this cold give
> in return.


That’s your agenda, not mine. I have no interest in ‘research’ in this document. This is purely pragmatic and operational.

> 
> 5. Couple of nits for the first part of the doc appended below.
> 
> Cheers
>    Toerless
> 
> 
>> Abstract
>> 
>>    Routing and addressing are inexorably tied, and the scalability of
> 
>     ^
> Nit:
>    prepend "In the Internet architecture"
> 
> E.g.: If we would have a better architecture, including LISP, we would
> arguably have a less than inexorable tie... i think.
> 
> ...
> 
>>   The Internet depends upon the efficiency and scalability of the
>>   routing system.
> 
>>   Without effective routing, no traffic can be delivered. 
> 
> Nit: Why is effectiveness relevant here ? If you think that scaling limits
> impact effectiveness, please say so explicitly instead of letting it be
> subject to readers guesswork.
> 
>> 3.  Routing and Addressing
>> 
>>   The routing subsystem of the Internet is responsible for discovering
>>   paths from any point on the Internet to any other point.
> 
> Nit:
> 
> s/discovering/announcing/ ?
> 
> Arguably if we had a better internet architecture where routes are
> discovered on demand, we again might have a different scalability discussion.
> Did i mention LISP ?
> 
>>   For routing to function, there must be specific names for hosts.  The
>>   architecture of the namespace for these names is a critical decision,
>>   as these names will have global scope.  When we also use these names
>>   as a binding to a location in the network, we call these names
>>   'addresses' and the namespace that they are taken from an 'address
>>   space'.
> 
> Nit:
> 
> I don't think its necessary or beneficial for this document to try to
> invent how IP addresses are a type of name, and what properties names
> have to have to be called addresses. It just creates another instance
> of a neverending side discussion. E.g. I don't think we stop calling
> IP addresses IP addresses even in instances where they are only identifiers
> and not locators. Did i mention LISP ?
> 
> E.g. Suggest to leave away mentioning of names, just statig the facts
> that in the routing architecture of the Intenet, IP addresses are
> used to locate hosts.
> 
>> 
>>   Scalability is a central concern for routing.  Each item of
>>   information that routing must propagate around the network requires
>>   processing power and memory for storage throughout the network.  This
>>   scales with the size of the network.
> 
> Nit: Same number of routes, e.g.: 10,000, case A), small network with
> 100 routers, case B) large network with 5,000 routers. Q: How is routing
> in the B) network 50 times more expensive than in the A) network ?
> Are you just adding up the resource requirements across the routers ?
> IF so: why is that an interesting metric ? E.g.: IMHO the cost of
> routing within a router for example with DV (best case) does not increase
> with the size of the network. At best with the number of neighbors.
> Aka: Either leave out the argument about the network size or make it more
> precise.


This is correct. It scales with the number of prefixes. Fixed.

> 
>>   If routing also scaled linearly
>>   with the number of hosts, then the cost of running the routing system
>>   would grow as the size of the network times the number of hosts,
>>   which is clearly problematic.  For this reason, we cannot have a
>>   routing subsystem that just carries individual host routes.
> 
> Nit: Its good enough (and IMHO more true), just to look at the cost of
> linear growth of routing if we didn't have aggregation. That has been
> the problem all along.
>> 
>> 4.  Abstraction and Aggregation
>> 
>>   Instead, we seek to define groups of hosts and treat them together as
>>   a single abstraction, commonly known as a 'prefix'.  We call the
>>   process of combining addresses together into a prefix 'aggregation'.
>>   Under some circumstances, prefixes themselves may also be aggregated
>>   to form another prefix, resulting in a recursive structure.  If
>>   prefix A is a proper subset of prefix B, we say that A is 'more
>>   specific' than B and that B is 'less specific' than A.
>> 
>>   We can then define the routing efficiency of a specific prefix as the
>>   cost of carrying that prefix, plus all of its more specifics,
>>   integrated across the entire network, and divided by the number of
>>   host addresses subsumed by the prefix.
> 
> Nit: this looks like a too complex formula. Just say a prefix has an efficiency
> of N if it covers N hosts or the like.


That would not cover the costs of people advertising more-specifics.


> 
>>   It is well known that abstraction obscures important detail and that
>>   abstraction in routing can cause sub-optimal paths, resulting in
>>   extra hops, wasted bandwidth, and managerial difficulties.  As a
>>   result, there will always be a trade-off between scalability and
>>   optimality when introducing abstractions.
> 
> Nit: i'd prefer to stick to the term aggregation instead of bringing
> in abstraction as an equivalent. But the text also used prefixes already,
> so why not just make the statement about routing for prefixes and maybe
> add that the shorter the prefix the greater the risk of such sub-optimalities ?


That is simply not true. /8 is not somehow less optimal than /16. It depends on the topology, not the prefix length.

> 
>>   When optimality is paramount and simple reachability is insufficient,
>>   the routing subsystem has additional mechanisms that allow network
>>   operators to make different path selection choices, sometimes
>>   intentionally ignoring or explicitly working against abstraction.  We
>>   call this broad set of mechanisms 'traffic engineering'.
> 
> Nit: WOuldn't the most simple example be a prefix route and then to get
> a more optimum path for some important hosts in that prefix be another
> longer-prefix route just for those host ? I don't think we would call that
> setup traffic-engineering. Aka: Not sure why we need to bring in yet another
> loaded term (traffic engineering). Also: Did i mention LISP (is that
> traffic engineering ?) But it would equally provide tools for more optimality.


That would definitely be traffic engineering.


> 
>> 
>> 5.  Abstraction Boundaries
>> 
>>   Abstractions have three different boundaries that we will be
>>   concerned with:
>> 
>>   Abstraction Administrative Boundary
>>      An abstraction's administrative boundary occurs at the topological
>>      interface between the abstraction's administratively controlled
>>      network and other administrations.
>> 
> topological interface used but not defined.
> Would prefer to stick to prefix or aggregate instead of abstration.
> 
>> 
>>   Abstraction Naming Boundary
>>      An abstraction's naming boundary is the topological container of
>>      all of the host addresses within that abstraction.
> 
> New word for prefix ?
> 
> Aka: overall a bit too much abstraction/reinvention of terminology in
> the doc for my taste, makes the whole problem look more convoluted as
> it is IMHO.
> 



Regards,
Tony