[RRG] Thoughts on the RRG/Routing Space Problem

[Russ White <riw@cisco.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I was reading through all the various threads here over the last couple
of weeks, and also going through some of the proposals, and through some
of the slide decks that have been sent out, and I have a couple of
questions, actually.... These might seem fundamental, and maybe they're
answered someplace, but I thought they were worth asking, anyway. Maybe
someone can just say: "These are dumb questions!," I don't know. :-)

1. There seems to be a concensus that splitting the "transit" address
space from the "end user" address space is "the solution." I'm a little
worried about this assumption, for various reasons. I'm hoping someone
can tell me I'm crazy, and that my disquiet is just based on a figment
of my imagination.

Looking back to this quote from one of the slide decks:

Clark: "There are clearly two classes of network entities, subscribers
and providers; there may be a gray area but that is not important."

I'm under the impression that the "gray area" that's "not important" is
actually growing in size, rather than reducing in size--that the split
between transit and host/service isn't along provider/customer lines,
but rather within all of these networks, and that this is becoming more
common, rather than less.

For instance, it appears a lot of providers are moving out of the "pure
transport" space and into offering services, as well, because services
tend to produce higher revenues (?). At the same time, there are a lot
of "enterprise" customers who now host services directly, as well as
provide transit for others who provide services. For instance, a large
retailer might provide shelf space and transport for a brand name within
their store, rather than directly managing that shelf space themselves.
This happens in all sorts of venues--governments, theme parks, retail
spaces, etc., and I think this might be becoming more common rather than
less (?).

Does anyone else have any sort of sense on this? What's the impact if we
push an artificial split into this area, and find we're wrong--that the
gray area is, in a sense, the *only* interesting area with good revenues
for everyone?

2. There seems to be some idea that traffic engineering is primarily
done along the "provider/customer" edge, which I don't think to be true.
In fact, I think there are two sorts of "traffic engineer" in view, the
first of which is within a given AS, and the other of which attempts to
influence the point at which traffic enters an AS. These two sorts of
traffic engineering are, generally, opposed to one another, or rather,
in many situations probably attempt to influence traffic to take
different paths.

I think we've oversimplified the concept of "traffic engineering" in our
thinking, and therefore we've not considered the full impact of it. Is
it really true that providers don't care where traffic enter their
networks? If they do, then with what granularity do they care?
Traditionally, traffic engineering is done to the granularity of the
reachable destination. What new mechanism will be deployed to allow
granularity of this same fineness, and yet not cause the table size to
increase?

Anyway, those are my dumb questions. Maybe they'll spark some useful
discussion somewhere along the way.

:-)

Russ

- --
riw@cisco.com CCIE <>< Grace Alone

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHTy14ER27sUhU9OQRAmxqAKDO+or6gGfJvUUu/TYrWoWX1AgXFwCg0U0W
zdncT90NV0smJgfxPjnxwuk=
=BcBe
-----END PGP SIGNATURE-----

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