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

[Toerless Eckert <[e-mail]>]

Tony,

Thanks for the document. Certainly an interesting topic to discuss.

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.

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). In this
universe i could solve the problem through a combination of two
mechanisms alone:

a) goegraphical aggregateable allocation of address space by registries
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.

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.

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.

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.

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

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

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

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