RE: (multi6) requirements draft comments

["J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>]

    > From: "Tony Hain" <alh-ietf@tndh.net>

    >> What I meant was that all the people who are connected to both:

    >> - i) the same segment of the York County Cox CATV system here
    >> in Virginia,
    >>       and
    >> - ii) the same Verizon DSL office
 
    > you distinctly claimed a difference from metro, but in your example you
    > have an implicit metro context.

You clipped the next line:

    > would share the same one-level-up topological naming entity

Let me try this another way. Let's define a "chunk" of a graph as a set of
nodes, and the arcs between them, such that you can get from any node to any
other node by traversing only nodes and arcs that are part of the chunk. In
the map (graph) of the network, I can then replace that "chunk" of the
map/graph with a single node representing that "chunk"; i.e. draw a new,
simpler map/graph with one node where all those nodes used to be. This
process can recurse; i.e. I can define some "meta-chunks", and draw yet
another map/graph.

(You can fine a picture of some of this process here:

    http://users.exis.net/~jnc/tech/routing_slides.html

Look for the header "Abstraction Hierarchies", and then look at the second
diagram. I guess I should add a picture showing the simplified graph, but
I assumed it's pretty obvious what it looks like.)

Now, what I was doing above is taking a map (graph, actually) of the real
network, including all these houses Hk which might be multi-homed, and trying
to draw (nested) circles around portions of that actual connectivity
map/graph, that define "chunks" of the map/graph which are useful for making
the routing scale.

I have defined a particular "chunk", the set of end-nodes Sij, as ecompassing
the following nodes in that map/graph: the node for that particular cable
installation from that cable provider, Ci (I say "that particular ..
installation", since other cable installations belonging to that company are
elsewhere in the map), the node for that DSL office from DSL provider, Dj
(same comment - their other offices are elsewhere in the map/graph), and all
the host nodes Hk such that any Hk has a link to both Ci and Dj, along with
all the arcs among them.

Now, do the same thing for all the other local ISP's hardware segments, and
the customers who are connected to them, producing a map/graph with a
"simplified" representation of the connectivity in the local area. I can now
recurse this process, and group things into even bigger aggregates.


The *key* difference here from metro is that I *start* with the actual
connectivity map, placing no constraints on how it is connected. (E.g. there
may be no direct link from Ci to Dj, except through the customer nodes -
which of course do not forward traffic.) From that, I then asssign addresses.

This is very different from metro, which assigns addresses to things, and
then places constraints on how things can be connected - and never changes
the addresses no matter how the actual connectivity changes.

For instance, notice that if customer Hk drops cable provider Ci and signs up
with a new provider, Cq, they get a new address, since they are now part of
the set Sqj. This is distinctly different from what metro addressing does.

 
    >> "REAL TOPOLOGY IS KING". For routing, the *only* thing that matters is
    >> *actual* connectivity; i.e. the actual wires and routers.
    >> ...
    >> the K-K lesson, which is that the way you get the routing to scale,
    >> even in mindbogglingly large networks, is to use LOTS OF LAYERS OF
    >> ABSTRACTION.
 
    > I am sure you are well aware of the contradiction in those two
    > statements in the abstract

There is no contradiction. Perhaps you are being confused by my terminology,
where I am using the term "abstraction" in the graph sense, not the software
engineering sense.

I use the term "abstraction" of (sub) graph to mean a simplified
representation of a "chunk" of a graph - but not *neceessarily* one that can
be produced by any repeated replacement of smaller sub-"chunks" of the
"chunk" with nodes (that process, and the results, I tend to call
"aggregation").

Let me give you a concrete example. Suppose I am a small ISP, with 5 routers
total, four of them border routers, A-D, and one internal router I. I have 4
links, directly connecting each border router to I. Here are some
"simplified" representations of that "chunk" of the map/graph that you can't
produce by an aggregation process:

- a graph in which all four border nodes are connected to each other directly
- a graph in which the four border routers are connected in a ring (i.e. A to
  B, B to C, etc)

So I tend to use the word "abstraction" to mean what most people mean by
"aggregation", but as a more encompassing technical process.

In particular, in their scaling work, Kleinrock-Kamoun uses only
"aggregation" (as defined here) steps to produce simplified graphs.


    > We know how to aggregate when all the end sites play nice and constrain
    > their service to a single ISP, but they refuse to do that. We also know
    > how to implement a scalable metro approach, but ISPs refuse to do that.
    > Since the end sites are the holders of the money, the ISPs will
    > eventually loose this battle, and lacking any revolutionary technology
    > will have to implement some degree of metro.

That may well be.

FWIW, the addressing approach I have outlined allows both the users to
multihome, and the ISP's not to have to be forced to interconnect - but it
does it by using address allocation mechanisms that both sides may not like:
the users have to renumber when they change providers, and the ISP's have to
give up some control over addressing.
 
However, I have no way to control what the market will do - and indeed, my
addressing scheme may not even be an option for people.

I'm simply trying to explain to people what's fundamentally possible from the
routing side.

	Noel