Subject: RE: (multi6) requirements draft comments

From: "Tony Hain" <[email-masked]>
Date: Mon, 17 Dec 2001 17:18:53 -0800

Michel Py wrote:
> I think that the original intend of 3.1.2 for inbound was to prevent
> flaky destination address selection schemes such as
> round-robin. The way
> I read it is that, if a multihomed site as multiple PA
> addresses but no
> PI address, the address selection algorithm to pick which of the PA
> address is to be used must pick the best one for a specific source,
> which probably means that the address selection must know about the
> network topology, which means either a hook into BGP or some other
> sophisticated mechanism yet to be defined.
Having a host know the topology is the flaky scheme. DNS round-robin
works fine to isolate the address selection from the topology knowledge.
That section appears to be trying to describe the case that SiteA has
the ability to inject a long prefix into all ISPs. My concern is that it
states a site MUST be able to control traffic flow, when it is the
receiver. This is technically not possible since the holder of the
packet can choose any path it wants by ignoring the detailed
announcement from the receiver.

> There might be other ways (TCP hacks/stack hacks), but the PI address
> being the one that is configured on the hosts is the only proven one.
> Note that the PI address could (although I do not recommend it) be a
> site-local address with NAT.
The point was that the correspondent must perceive that the address
didn't change, else the interruption will be more than a simple packet
loss. Use of a NAT is orthogonal because the public side of the NAT has
the same issue.

Tony

---

From: "Michel Py" <[email-masked]>
Date: Tue, 18 Dec 2001 07:28:18 -0800

> Dec 18, 2001 at 09:26:09AM +0100, Brian E Carpenter wrote:
> Michel Py wrote:
> > This is vague indeed and I would not mind dropping 3.1.4 although it
> > does not bother me.
>
> I think it needs to stay in, but the phrase "or application, NNTP, for example, "
> should be deleted. That would leave the "example" sentence as
>    For example, customer C homed to ISP A may wish to shift traffic of a
>    certain class to ISP B as matter of policy. 
> which is necessary and sufficient IMHO.
>
> We could refine it further by saying "shift outgoing traffic" to make it
> clear that this is not policy based routing.
>
> Joe Abley wrote:
> This sounds good to me.

Sounds good to me too.
Michel.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 18 Dec 2001 09:27:23 -0800

>> Christian Huitema wrote:
>> I believe that we will see multiple solutions, and I would
>> categorize these solutions in two large classes: the solutions
>> that require the cooperation of the network service providers,
>> and the solutions that don't. My contention is that a mass market
>> solution should not require any action from the ISP.

>> Craig A. Huegen wrote:
>> While I agree with your sentiment, I believe there are multiple
>> classes that must be considered.  I don't believe that a user
>> should be able to inject global prefixes from a cable modem and
>> a DSL line at home; however, I do believe there's room for global
>> prefixes to be injected by large, multi-national enterprises as
>> end-users.  I ask for caution within this community not to condemn
>> a solution that may be right for the very large end-users because
>> of a fear someone might want to apply it to home networks --
>> they're vastly different beasts.

I fully agree with Christian and Craig here. I have proposed that idea of different classes a while ago on the mailing list (if you look into the archive, the title was "a new spin on multihoming: multihoming classes). It did not seem to trigger much interest at the time.

Michel.

---

From: [email-masked] (Sean Doran)
Date: Tue, 18 Dec 2001 18:41:20 +0100 (CET)

| I fully agree with Christian and Craig here. I have proposed that idea =
| of different classes a while ago on the mailing list (if you look into =
| the archive, the title was "a new spin on multihoming: multihoming =
| classes). It did not seem to trigger much interest at the time.

Unfortunately, IETF working groups are not captive audiences,
and the volume of drafts means that anyone who participates
in several WGs will have a hard time being motivated to keep
up with a large fraction of them.

While Thomas and I are obliged to try to focus everyone on the two
drafts in the multi6 charter, I don't think many people would
mind some small degree of "hey, go look at my draft-xyz-..., which
is relevant", when it is indeed relevant to the discussions at hand.

	Sean.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 18 Dec 2001 19:40:10 -0800

I agree with Michael on the three spaces here, and I will add that, since the current focus of this working group is "site multihoming", we should acknowledge mobile as part of the multihoming problem and decide if it is within the scope of the WG or not.

>> Michael Richardson wrote:
>> I believe that there are three solution spaces:
>>  1) large multi-national entreprise solutions.
>>     (if you have geographically relevant addressing, either via
>>     geo-PI, or via national governments doing all assignments. Perhaps
>>     not a reality in the "free markets", but possibly true for other
>>     less free areas, but also places like Antartica, the Moon, Mars...)
>>    
>>     This is more or less the BGP solution space.
>>   2) network layer solutions.
>>     mobile-IP like systems.
>>       Some people believe that this requires some kind of global PKI
>>       on the reverse name space. (note: PKI = PK infrastructure, which
>>       maybe PK+DNSSEC. It may not imply x509/pkix)
>>       opportunistic-encryption-like-tunnel systems.
>>       Given the above global PKI, you can assign PI addresses to everyone
>>       which are *not* routed. You can then advertise how to get to these
>>       places by putting stuff into DNS reverse map.
>>              (see draft-richardson-ipsec-opportunistic-03.txt)
>>       This is no different than the mobile-IP system, it just never tries
>>       to optomize anything.
>>      HIP-like systems- a variation of the above where IP addresess
>>              become meaningless, and hashes of public keys terminate
>>              connections.
>>   3) transport layer solutions.
>>     Just use SCTP for everything with PA addressing.
>> None of these solutions are even exclusive. I can see all three systems
>> occuring at the same time.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 18 Dec 2001 20:11:50 -0800

Brian,

>> Fully agree. All I am suggesting right now is that we don't
>> *assume* PI is the answer for multi6.

Enhanced PI is the SHORT-TERM answer to multi6.

>> If I thought it would scale for tomorrow's Internet, we
>> wouldn't be having this conversation.

It does not scale, and we know it (although there are ways to
scrounge 10 or more years out of it). And, a bad solution is
better than no solution.

>> We agree. So don't build PI into the requirements of multi6.

I am not advocating to build PI into the requirements of multi6.

>>>> This tells me that the road we need to pursue is an
>>>> evolution of the current model as a headstart and continue
>>>> to research other things as incremental changes
>> Please don't build that into the requirements either. Maybe
>> somebody will invent the slam dunk when they see the agreed
>> requirements. (Unlikely, but we mustn't exclude it by
>> construction.)

IMHO, this is not relevant. If somebody invents the improbable
universal solution that everyone here has failed to grasp,
we will all agree to toss the requirements overboard.

What I am advocating for is being realistic:

1. As Randy said, we do have a collective responsability to
bring the IPv6 community more or less what exists today for IPv4
and try to clean it as we go.
*** hint ***
http://search.ietf.org/internet-drafts/draft-py-multi6-mhtp-01.txt

2. This is not enough. No single solution actually answers the
big-picture problem and there are three main areas, or classes, or
spaces or whatever that needs to be addressed: big honkin' setup,
home/soho, and mobile, probably with some overlap.

3. The current requirements draft is blocking solutions from being
developped and, as Christian said, it's time to put it to bed.

Michel.

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Wed, 19 Dec 2001 11:46:30 -0500

> From: Eliot Lear <[email-masked]>

    > one of the people who invented the concept of routing (and patented the
    > multiprotocol router)

Alas, I wish I had! I did co-invent the concept of the multi-protocol router
(after some investigation, it appears that Bill Yeager at Stanford was doing
some multi-protocol stuff at about the same time as I was, at MIT), but we
never had the wit to patent it! Too bad, we'd have been bazillionaires!

Also, I didn't invent the concept of routing (in the sense of internetwork
forwarding) - that was some collection of Cerf, Kahn and a couple of other
people.

	Noel

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 19 Dec 2001 14:04:00 -0800

> What's more interesting is to think about what happens when there's a
> failure. This is *not* a situation that K-K talks about - they are
simply
> analyzing the most efficient naming hiearchy for optimal (in terms of
> minimum table size) routing.

Isn't it the case that, in order to maintain optimality in the face of a
graph change, you have to entirely revisit your aggregation structure,
which would be akin to renumbering the Internet?

-- Christian Huitema

---

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

> From: "Christian Huitema" <[email-masked]>

    > Isn't it the case that, in order to maintain optimality in the face of
    > a graph change, you have to entirely revisit your aggregation
    > structure, which would be akin to renumbering the Internet? 

First, you'd only have to renumber if you wanted to to maintain absolute
optimality. Since absolute optimality produces a routing table of size
e*ln(N), i.e. as I mentioned before a 60 entry routing table for a 10^8 node
network, somehow I don't think we have to maintain absolute optimality!

Second (and this is really irrelevant, given the point above, but in true
routing-graph-theory-geek style I mention it for completeness) I expect that
the vast majority of connectivity changes in a graph can be handled with a
renumbering over a scope that's less than global.

	Noel

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 20 Dec 2001 08:44:25 -0800

>     >> Yes, but... if you have a solution which works for 10^7
multi-homed
>     >> houses, and works well, why bother to have a separate one for
>     >> companies?
> 
>     > If we can find a way to multihome 10^7 sites using a single
route-
> name,
>     > then I'm all for it.
> 
> ??? I never implied that any routing-based solution would allow all
10^7
> sites to use a single routing-name.

I think that when evaluating any proposal, we should try to define how
it scales by using standard complexity analysis. I can myself see at
least two interesting variables:

   1) The number S of multi-homed sites
   2) The number H of "homes" for a given site

There are multiple aspects of scaling, and we should review them. Among
the interesting variables are:

  - The impact of multi-homing on multi-homed hosts, 
  - The impact of multi-homing on "correspondent" hosts,
  - The impact of multi-homing on Internet routers, 
  - The impact of multi-homing on "site exit" routers.

Different solutions have different characteristics. The so-called "PI"
solution, for example, has an O(1) impact on multi-homed hosts and
correspondent hosts, an O(H) impact on site exit routers, and an O(S)
impact on Internet routers. The "host centric" solution that I put
forward has an O(H) impact on hosts, correspondent hosts, and site exit
routers; and the same impact on routers as standard routing, i.e. in
theory O(log S), or maybe O(log S + log H).

Expressing the complexity in these terms helps us understand the impact
of various scenarios, e.g. "what if every home network is multi-homed",
or "what if every site decides to have 100 providers"...

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 20 Dec 2001 13:27:37 -0800

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

This control issue limits the type of aggregation that we can adopt, in
the sense that aggregates have to somehow match the ownership of
resource. Once we take this constraint into account, it is very unclear
that we can devise an addressing plan that matches the arbitrary graph
resulting of multi-homing. The control issue is also the rubbing point
in explicit routing solutions. Typically, providers don't want users to
decide which of the provider's resource will or will not be used by a
particular set of packets. In fact, this is one of the reasons I like
the model of having multiple addresses for multi-homed sites: by
choosing the address explicitly, the end users can get some of the
benefits of explicit routing.

-- Christian Huitema