Subject: My impressions of the Sunday meetings....

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 21 Nov 2002 03:11:18 +0100

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 -

---

From: Christian Kuhtz <[email-masked]>
Date: Wed, 20 Nov 2002 22:10:03 -0500

Hello,

I wasn't able to attend, but I would like to express my opinion as 
well based on what I have seen and reviewed so far.  

I very much agree with the points presented in this email.  I have found
the requirements doc of little usefulness in trying to develop approaches
in how to come up with a solution.  (this isn't intended as a stab against
anyone's pride, just an observation).

It came across in the discussion on this list as if many of these proposals
are good for solving world hunger and cooking coffee in the morning.  Right
now, a glass of cold water is all I really need because right now we have 
nothing, and people are starting to think about getting thirsty someday. ;)

So, coming up with a solution near term that solves a limited set of 
problems to me is preferable to designing the swiss army knife out of
the box.   And I'll take the swiss army knife (which is what BGP-4+ has
sort of mutated into) whenever it is ready.  As long as I can make do
and solve some of the most pressing problems near term and have a rough
plan of getting somewhere else later.

The most pressing problems to me DO NOT include an individual host's
ability to pick and chose a path out of several options.  They DO
include for an administrative domain to be attached to multiple paths
and being able to chose which based on its own administrative or even
just the closer-to-the-DFZ-entity's administrative preferences.

I don't care to solve the 'multi-homed DSL and cable' site problem 
right now.  The more pressing issue is those customers who have 
traditionally been sophisticated and/or large enough to be multipathing
candidates.  Those are what I would like to see developed as a priority,
and until we can tackle one space, I'm sorry.. I don't care about the
proud and few power users who do not generate the lionshare of my
revenue.

If the 'multi-homed DSL and cable' site does get solved by accident or
small amounts of effort, cool.  But I'm not willing to spend a great
deal of energy on that right now.

I also do want to hear radical solutions which question our thinking of 
what we consider accepted facts.  MPLS-VPN is an example of a bastard
child which actually has a practical application and is being deployed
commercially.  Yet, it did rattle quite a few people at its inception.

So, out of the box thinking is good.  Things like.. significance of 
address space over great 'distances' is another one.  Is it neccessary
for things to show up in the DFZ that may rest in layers around it? Is
there a way we can abstraction very complex topology to the DFZ?  Even
if that means perhaps one site not directly attached to the DFZ having
multiple representations in multiple address spaces.

But, before we can do any of that.. let's narrow down this monstrous
scope to a managable piece!

> we don't know what problem or part of the problem they address.

I very much agree.

> So, flames, comments and free beer are welcome!

Speak up next time you're in Atlanta. ;)

Thanks,
Christian

---

From: Vijay Gill <[email-masked]>
Date: Wed, 20 Nov 2002 23:21:26 -0500

> anyone's pride, just an observation).

The thought was that whatever solution(s) is/are proposed, they should at
least solve for the commonly encountered problems we see today. Just
because we have the routing problem solved by whatever means does not
imply that the problems we hack around today are going to be magically
fixed. Capacity to certain AS's will continue to lag behind traffic
growth, AS's will still fall over with depressing regularity, some traffic
paths will be more expensive than others, etc etc.

/vijay

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 21 Nov 2002 18:44:50 +0100 (CET)

Hi everyone,

We're going to have another "rebel" meeting this afternoon at 3.30.
We'll meet in front of the consulate room, as we're still waiting to see
if we can officially book a room or we have to be creative again.

> or involve a new routing paradigm in one way or the other.

Yes. However, I'm also getting a sense that most people agree we can't
wait this long. Christian took some steps down an incremental steps path
towards multi-address multihoming, and there are also more than enough
ideas for low-ambition routing solutions to take the edge off.

Another interesting development is that the v6ops wg just reached
consensus that it should work on non-routable/for-local-use-only address
provider independent address space that should be used as a replacement
for site local addresses for most uses. And immediately people started
yelling this address space should be routable after all.

> the current requirements draft will be a good starting point.

So lets discuss this in the meeting this afternoon. As I'm out of
contact with the other "rebels" I'm not going to suggest a full agenda
right now, but this should definately be on it.

[Lots removed]

> One way going forward that I prefer is to ask IANA delegate a
> should not be to hard to accept by the enterprises.

There are more ways to skin this cat. Now I haven't been a great fan of
what's happening with the requirements in this wg, but for this specific
purpose it might be useful to draw up some requirements.

Iljitsch

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 21 Nov 2002 20:15:24 +0100

> wait this long. Christian took some steps down an incremental steps 

Which is also what I concluded. We will need to do this in steps. If 
this is based on a host solution, my suggestion of PI space or 
something else remains to be seen. If we go for a solution that would 
require host or router implementation we still have at least two years 
to go. I don't think we have even that.

> yelling this address space should be routable after all.

I assume you mean the IPv6 WG? My opinion is that we should use global 
addresses everywhere but we "lost"...

However, I am really worried that we keep mixing a routing scalability 
issue with an addressing issue. I am not sure these needs to be related 
at all.

There is a lot more to be said on this issue but it belongs in the IPv6 
WG not here.

> right now, but this should definately be on it.

Well, I would prefer to keep the discussions around the document on the 
mailinglist (which of course doesn't stop us from discussing it anyway) 
as there have no announced multi6 wg meeting and to start 
"semi-offical" discussions with this short notice does not seem fair.

> purpose it might be useful to draw up some requirements.

Again, I think we need a requirements document that actually gives us 
directions on the solution in terms of capabilities and scalability as 
well listing the lessons currently learnt (which I think the current 
document is closer to). Then as said above and in other emails, I think 
we need to buy time and to me the easiest way to do this would be to go 
with what we have and that we know. I haven't seen anyone do a real 
analysis on the impact routing table growth with doing controlled 
address allocations.

- kurtis -