Subject: RE: (multi6) requirements draft comments

From: "J. Noel Chiappa" <[email-masked]>
Date: Wed, 19 Dec 2001 17:22:42 -0500

> From: "Tony Hain" <[email-masked]>

    > So there is a prefix for every combination of possible providers a
    > customer can subscribe from

No - at least not the way you seem to be meaning when you say those words).
I.e. you seem to think everyone with service from Verizon DSL and Cox Cable
would share the same prefix - which is distinctly not what I meant.

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

would share the same one-level-up topological naming entity - and that would
be a very different one-level-up topological naming entity from the people
who have Cox CATV service in, say, Maryland, and who are also getting Verizon
DSL service from an office there.

Anyone thinking about anything related to routing needs to take a sharp
implement, and engrave on their forehead "REAL TOPOLOGY IS KING". For routing,
the *only* thing that matters is *actual* connectivity; i.e. the actual wires
and routers. I often hear people *claim* they are paying attention to this -
but then they go off and say things which show clearly that they haven't
*really* understood it (and taken it to heart).

Just because two wires are owned by the same company doesn't mean a damn
thing. The only thing that matters is the real network topology - i.e. the
graph of the real, physical assets that make up the network.

The other thing that people need to keep firmly in mind is 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. Three or four real
layers of abstraction for a network of 10^8 nodes is *not* going to cut it.

    > How would the providers know where the overlaps are to route correctly,
    > ... How would routing work if those overlap areas were discontiguous?

Some of these questions seem to be based on your incorrect understanding of
what I was proposing. Both of these questions make no sense if each area of
overlap has a (globally) unique Sij name (but one which may itself be subsumed
in the name of a one-level-higher topology aggregate).

    > This approach moves the scaling problem from the technical space to the
    > administrative space, where the complexity would create prohibitive
    > costs.

No, I was speaking of a system that basically automically assigned
routing-names, and did so basically *purely* on the basis of connectivity;
i.e. it would deduce for itself where to put abstraction naming boundaries.
The *last* thing I want is bureacrats trying to do it.

No doubt this would not sit well with the providers, but I don't mind waiting
for the tide to cover their thrones.

	Noel

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 20 Dec 2001 10:39:53 -0800

> - ii) the same Verizon DSL office

Just checking, because you distinctly claimed a difference from metro,
but in your example you have an implicit metro context.

> and routers.
...
> 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, and the fact that the latter is why people
frequently loose focus on the former. The piece that sits in between
those two viewpoints of the world is the practical reality of the
routing protocol technology and the application of that by mere mortal
(though frequently sub-human) operators. Yes we need to focus on real
topology, but practical reality of current technology says that we need
to constrain the degrees in freedom to something managable. 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. My suggestion is that they do this as an
overlay to the PA system so they get the best of both worlds.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Dec 2001 11:29:49 +0100

Tony Hain wrote:
...
> We also know how to

OK, we don't discuss business models in the IETF, but this is the key
issue in moving to any kind of *fixed* address alocation other than ISP
based PA.

["fixed" is a relative term - I mean one that isn't automatically
generated on the Noel model, not one that is fixed for all time.]

The reason I've railed against Tony's PI proposal is because I have
serious doubts whether market forces will lead to the adoption
of metro (or metro-like) addressing and the consequent creation
of ISP-neutral metro exchanges. But in any case, it's something
totally outside the IETF's control. It's also completely compatible
with PA addresses, simple by giving PA blocks to the metro exchanges
if and when they appear.

However, returning to our topic, that would make the metro exchanges
key failure points in the multihoming system. That breaks
requirement 3.1.1 in the draft. Do we want to insist that the
solution MUST accommodate failure of metro exchanges?

  Brian

---

From: Andrew Partan <[email-masked]>
Date: Fri, 21 Dec 2001 11:23:30 -0500

> solution MUST accommodate failure of metro exchanges?

We should insist that the solution MUST accommodate the failure of
any single point.
	--asp

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 21 Dec 2001 10:12:11 -0800

> issue in moving to any kind of *fixed* address alocation

I agree we are not in the business of proscribing any specific business
model, but we can't define mechanisms that are useful without some
context of the models they might be used in. I do believe it is within
our realm to describe a tool and a potential set of business models that
might apply.

> of ISP-neutral metro exchanges.

In the abstract I would agree, but in reality the market has already
created the ISP-neutral exchanges in most of the significant metro
areas. What they are missing is an addressing plan that would leverage
those.

> But in any case, it's something

All we can do is write something like a BCP, and let the market decide
if that is viable. As far as the use of PA blocks vs. the PI ones I
proposed, I really don't think it makes too much difference, the
architectural point is to isolate the end customers from the set of
transit service providers they may subscribe to.

> solution MUST accommodate failure of metro exchanges?

Yes there should be no single points of failure. The description of a
distributed exchange in my current draft is admittedly a hand-wave, and
likely inadaquate, but I agree we need to avoid this problem.

Tony