My impressions of the Sunday meetings....

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

I am not sure what this is worth - but I though I should write up some 
of the impressions I got from Mondays meetings as well as some thoughts 
of my own (for whatever that is worth...)

The first thing I found interesting was that almost everyone saw the 
current proposals as temporary or partial steps to a final solution.  I 
don't think that has been very clear on the mailing list so far.

Second, almost everyone agreed that the final solution will need to be 
or involve a new routing paradigm in one way or the other.

Third, almost all could also see a distinct role for the current 
proposals going forward after/with a new routing solution is agreed upon

This said, what I felt was that there was no clear views (sometimes not 
even from the authors) what role the solutions currently being 
discussed would fill in going forward. Either in relation to a new 
routing solution or to what solution space they addressed. I said in 
the small group that met at 14.00 that what I felt was missing was an 
overview of the pieces both in the solution space as well as in 
defining what the problem space is. Thomas Narten put this even better 
in the evening session when he said that we where missing a road-map. I 
agree with this, but I am willing to go a bit further. After listening 
to some of the discussions and reading the proposals, I am not so sure 
the current requirements draft will be a good starting point. The 
current document does fill a role as describing the current problems, 
but it does not go all the way to outline different problem scenarios 
and group them. It does not either address the road map issue. This in 
my opinion is crucial for us going forward, especially in being able to 
judge the different host based solutions, as well as trying to keep us 
on track going forward (although this is the role of the charter and 
the milestones, we lack a more detailed per step problem description). 
We need a document to fill this gap.

I think that we need to take a step backward from the various solutions 
being discussed and try and start at nailing down the problems we are 
trying to address and what they imply. Without this distance we will 
get stuck in discussing implementation issues, just as is currently 
being done on this mailinglist, and not moving forward - mostly because 
we don't know what problem or part of the problem they address.

There is no "single" solution to this, but we need to better understand 
the problems, and have them written down. This might have been 
discussed before I joined the mailinglist some nine months ago, but as 
it has not left a document trace.

More, what we also need to get a better understanding of, is what is 
the scale and reasoning that we are engineering against. We are loosely 
talking about millions of multihomed prefixes, but we have no common 
understanding of the timelineing or what type or size of prefixes we 
are talking about. If it's the same multihomed prefixes that we are 
seeing today there is no hurry. For those of you who where in the 
ptomain workinggroup I raised the question to Geoff Houston if he from 
the CIDR-report had any view on the growth curve for multihomed 
preifxes. This is as Geoff pointed out very hard to determine, but it 
is also very crucial for what we are trying to engineer against, and it 
will give us a rough timeline for when we need what type of solution. 
Also, the prefix size of the "multihomingness" curve would gives 
valuable information into what size of solutions we need to be looking 
at. Currently we have none of this data but we are still gladly 
discussing solutions. Just to be clear here though, I agree that we 
will see millions of mulihomed-prefixes, but it makes a difference in 
the "final" solution if we are engineering to a solution we need in a 
year or five or if we will see 1M General Electric or 1M DLS customers.

Last, we also have none or very little insight into what larger 
allocation blocks will do for the number of routes. We have way to few 
allocations done to make any clear points in either direction.

So to my views on the solutions...

Generally - what I heard was that the Enterprise market seems to wants 
multihoming solutions before generally deploying IPv6. I have no doubt 
on this issue, and it more or less reflects my own experience. The 
reasons for this will vary. For the enterprise market, I don't think 
that a host based solution will scale or work in the long run. The 
enterprise networks will need something that involves a routing 
solution, but they will also need something that addresses a host based 
solution. What ever the solution will be - it will require either a 
change to the host implementations or to the routing code, not to 
mention the time for installation of IPv6 addresses. If we agree on a 
solution now, I think we will see general deployment in between 2-5 
years. I don't think we want to queue IPv6 deployment behind this 
issue. One way going forward that I prefer is to ask IANA delegate a 
_temporary_ PI space prefix - with the _clear notion that this address 
space will be called back_. This space would be allocated as "RIR 
ALLOCATED PA" in RIPE terminology. This would give us a jump-start and 
let some enterprises start out with trying multihoming, and IPv6 in 
general. It will also give us more operational experience and perhaps 
give us answers to some of my questions above. The additional prefixes 
created is something we can handle (with the current ~250 non-6bone 
prefixes I would say the problem is rather on the contrary), and with 
clear guidelines on when and how the addresses will be called back this 
should not be to hard to accept by the enterprises. This could also 
include a recommendation to the RIRs on trying to get more 
multinational enterprises to join as LIRs and thereby getting their own 
sub-TLA. From what I understood on the list this is has been proposed 
earlier but voted down. I have no idea what the reasoning was then, but 
I think this would be the fastest way forward as it does not require 
any changes anywhere, would most likely be easily accepted, and would 
give us wider acceptance of IPv6 as well as more data.

On the long term solution, I think that we will need a host based 
solution as well as a routing based solution if we wants this to scale. 
I will admit that I have been generally very skeptical to  a host based 
solution, but I have turned and do see a role for those. But for it all 
to come together we will need to address routing as well. In doing 
this, host based solutions might also be a transition as well as "early 
adopter tool". However, as said above, I think that we need to better 
understand how they fit together.


So, last a comment on the decision not to have a WG meeting in Atlanta. 
I think that we would not have made much progress on any of the 
proposals by having one, but I think that there would have been other 
reasons for having one. My main concern is that there also seems to be 
a belief that there is nothing happening on developing new routing 
models. I happen to know this is not really true but just as the 
"rebellion" sessions in Atlanta shed a light on the host based 
solutions, a update/presentation on what is being discussed in terms of 
routing models would have been god for all.

I know that I have suggested the creation of at least two drafts in the 
text above - and that following the IETF tradition it's just for me to 
go ahead and write them. I am very interested in doing so but have 
never done it before. I also first want to get more input on what I 
have said above from the mailinglist.

So, flames, comments and free beer are welcome!

- kurtis -