Subject: [RRG] Moving forward...

From: "Tony Li" <[email-masked]>
Date: Fri, 6 Jun 2008 09:45:36 -0700

In attempt to make some forward progress, I would like to see if we can rea=
ch rough consensus on the following.  Yes, I realize that it's a small topi=
c, but hopefully we can gain some momentum if we start be agreeing on easie=
r issues.

Our recommended solution should be applicable to IPv6.  It may also apply t=
o IPv4, but at the very least must provide a path forward for IPv6.

Comments?

Tony

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Scott Brim <[email-masked]>
Date: Fri, 06 Jun 2008 13:20:39 -0400

On 6/6/08 12:45 PM, Tony Li allegedly wrote:
> Our recommended solution should be applicable to IPv6.  It may also apply to
> IPv4, but at the very least must provide a path forward for IPv6.

I think applicability to IPv4 is equally important.  First, it will be 
years before there are more IPv6 packets than IPv4 packets -- longer 
than the time frame in which we must get our new technology deployed -- 
and efficient control of IPv4 forwarding is important.  Second, the 
granularity of IPv4 allocations is very probably going to go up 
dramatically in these final days, and that "state*rate" load will not go 
away for a long time.  We will have to carry it in routing until 
(unless) we deal with multihoming, hijacking, etc. for IPv4.

---

From: "Tony Li" <[email-masked]>
Date: Fri, 6 Jun 2008 10:22:57 -0700

Scott, 

|On 6/6/08 12:45 PM, Tony Li allegedly wrote:
|> Our recommended solution should be applicable to IPv6.  It 
|may also apply to
|> IPv4, but at the very least must provide a path forward for IPv6.
|
|I think applicability to IPv4 is equally important.  First, it will be 
|years before there are more IPv6 packets than IPv4 packets -- longer 
|than the time frame in which we must get our new technology 
|deployed -- 
|and efficient control of IPv4 forwarding is important.  Second, the 
|granularity of IPv4 allocations is very probably going to go up 
|dramatically in these final days, and that "state*rate" load 
|will not go 
|away for a long time.  We will have to carry it in routing until 
|(unless) we deal with multihoming, hijacking, etc. for IPv4.

Perhaps I need better wording, but applicability to IPv4 is not part of the
issue.  

Tony

---

From: Scott Brim <[email-masked]>
Date: Fri, 06 Jun 2008 13:25:57 -0400

> Perhaps I need better wording, but applicability to IPv4 is not part of the

So ... you're just asking about IPv6, and IPv4 is a different question?

I support "Our recommendation should be applicable to IPv6". :-)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 06 Jun 2008 13:33:33 -0400

I disagree.  I don't object to having a solution that also helps IPv4, 
but I do not think it is as important as getting something that works 
for IPv6.

We can keep the IPv4 net working for quite a while.  Particularly if we 
can provide some reason for folks to believe that v6 will matter.  If 
there is some actual benefit to the users (like better multi-homing) 
from IPv6, then not only will folks move towards it, but folks will 
believe that it is likely to matter, which reinforces the effect.  This 
in turn should help keep the pressure on v4 within the manageable range.

Note that trying to do this without solving the architectural probloems 
will merely result in v6 continuing to be ignored.  Or worse, v6 
becoming an even worse case of the problems we have with v4.

Joel

---

From: Scott Brim <[email-masked]>
Date: Fri, 06 Jun 2008 14:03:25 -0400

On 6/6/08 1:33 PM, Joel M. Halpern allegedly wrote:
> We can keep the IPv4 net working for quite a while.  

The point is, you don't have a choice.  What year do you think you will 
be able to stop making services available on IPv4?

 > Particularly if we
> can provide some reason for folks to believe that v6 will matter.  

iiuyc you are saying you are willing to support IPv4 if you can 
demonstrate to people that IPv6 is better.  What if you can't 
demonstrate that?  Are you going to stop supporting IPv4 in order to 
force people to move?

 > If

It's good to try to offer a better experience on IPv6, otherwise what's 
the point of IPv6 at all?  However, if you think that will remove the 
state*rate problem we are developing, I believe you are being overly 
optimistic.

> becoming an even worse case of the problems we have with v4.

If you only support the new architecture with IPv6, then you will be 
forcing people to move, but they won't be able to do so quickly.  And by 
the time we are able to successfully deploy IPv6 to any degree, there 
will be a significant expansion of IPv4 routing.  You will be inflicting 
suffering in order to get them to do what you want.  Can you tell that 
doesn't feel right to me?

I am not adamant that IPv4 MUST be supported equally.  If a design is 
clearly superior in a number of ways except that it cannot effectively 
support IPv4, then the benefits may outweigh the costs.  But I see 
clearly that it SHOULD be supported at least as well as IPv6.

And best of all is a design that allows us to deploy IPv10 a little more 
easily than the job we'll have with IPv6.

Scott

---

From: "Tony Li" <[email-masked]>
Date: Fri, 6 Jun 2008 11:10:49 -0700

|> |On 6/6/08 12:45 PM, Tony Li allegedly wrote:
|> |> Our recommended solution should be applicable to IPv6.  It 
|> |may also apply to
|> |> IPv4, but at the very least must provide a path forward for IPv6.
|
|So ... you're just asking about IPv6, and IPv4 is a different question?

Precisely.

|I support "Our recommendation should be applicable to IPv6". :-)

Thanks.   Any dissent?

Tony

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 Jun 2008 11:11:57 -0700

If the question comes down to IPv6 vs. IPv4, my answer
is "yes to both" - but, AFAICT IPv6 provides the vector
for scaling the number of end systems and edge networks.

Fred
[email-masked]  

>-----Original Message-----
>From: Tony Li [mailto:[email-masked]] 
>Sent: Friday, June 06, 2008 10:23 AM
>To: 'Scott Brim'
>Cc: 'rrg'
>Subject: RE: [RRG] Moving forward...
>
>
>Scott, 
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 6 Jun 2008 11:12:29 -0700

Can you put the complete claim phrase together now, so it is clear  
what you mean?

Dino

---

From: "Tony Li" <[email-masked]>
Date: Fri, 6 Jun 2008 11:31:42 -0700

|Can you put the complete claim phrase together now, so it is clear  
|what you mean?

Ok, take 2:

Our recommendation should be applicable to IPv6.  It may or may not also
apply to IPv4, but at the very least must provide a path forward for IPv6.

Tony

---

From: [email-masked] (Noel Chiappa)
Date: Fri, 6 Jun 2008 14:43:34 -0400 (EDT)

> From: Scott Brim <[email-masked]>

    > if you think that [IPv6] will remove the state*rate problem we are
    > developing, I believe you are being overly optimistic.

Yes, this is the important point. People's desire for non-DNS permanent
identifiers - aka PI space - means that the crippled IPv4/6 architecture is
going to have a permanent rate*state problem as the network grows. Since IPv4
and IPv6 are so similar, the same problems will occur in both, and the same
solution (in terms of the basic design and engineering) will work for both.

    > From: "Joel M. Halpern" <[email-masked]>

    > becoming an even worse case of the problems we have with v4.

If I understand what you're alluding to here, I think you're basically
agreeing with what I said above?

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

    > apply to IPv4, but at the very least must provide a path forward for IPv6.

Sure, but if it doesn't work for IPv4, is it going to have much uptake/use?

	Noel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 06 Jun 2008 14:55:33 -0400

That works for me.
Joel

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 06 Jun 2008 21:47:43 +0200

Tony,
> apply to IPv4, but at the very least must provide a path forward for IPv6.

I agree. As an IRTF research group (and not an IETF working group), we 
should focus our work on medium to long term solutions. If they happen 
to also work in short term fine, but short term should not be a requirement.

Olivier
-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium

---

From: David Williamson <[email-masked]>
Date: Fri, 6 Jun 2008 13:04:44 -0700

> apply to IPv4, but at the very least must provide a path forward for IPv6.

I completely support that statement.  It would certainly be nice to
have an architectural solution that would be easily retrofitted into
the IPv4 environment, but I suspect that anything involving IPv4
changes will suffer from the sheer scale of the problem.

IPv6, on the other hand, is non-negotiable.  I'd consider changing that
first "should" to "must"...but that's wordsmithing at an unnecssary
level of detail.

-David

---

From: Christian Vogt <[email-masked]>
Date: Fri, 6 Jun 2008 23:53:57 +0300

Scott -

although I overall agree with you that an RRG solution for IPv4 would
be welcome, I am skeptical with the two reasons you provide:

> First, it will be years before there are more IPv6 packets than IPv4
> packets -- longer than the time frame in which we must get our new
> technology deployed -- and efficient control of IPv4 forwarding is
> important.

You are assuming that (some of) today's holders of PI prefixes will
switch to RRG's solution and withdraw their PI prefixes from the
global routing table.  In my personal opinion, this is unlikely.  Any
RRG solution will have its cost, at least in terms of the effort to
set it up.  This cost will be a hurdle for today's PI prefix holders
to withdraw their prefixes.

More likely, IMO, is that the benefit of an RRG solution will come in
form of stricter guidelines for allocating *new* PI prefixes:
Applicants for PI prefixes can be required to use the RRG solution so
that the PI prefixes don't show up in the global routing table.  But
this will apply only to new prefix allocations, not to existing ones.
And hence it will apply primarily to IPv6.

> Second, the granularity of IPv4 allocations is very probably going to
> go up dramatically in these final days, and that "state*rate" load
> will not go away for a long time.  We will have to carry it in routing
> until (unless) we deal with multihoming, hijacking, etc. for IPv4.

Many of these smaller allocations will be provider-allocated, right?
RRG solutions won't be able to eliminate those from the global
routing table.

The remaining new PI allocations may not be numerous enough to have
a significant impact on the size and update rate of the global IPv4
routing table.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 6 Jun 2008 23:56:24 +0300

Tony -

> Ok, take 2:
>
> Our recommendation should be applicable to IPv6.  It may or may not
> also apply to IPv4, but at the very least must provide a path forward
> for IPv6.

Would this allow for separate solutions for IPv4 and IPv6?  RRG
shouldn't force itself to handle IPv4 with the same protocol that
handles IPv6 IMO.

But since your text talks about a "recommendation" and not a protocol,
this may actually not be an issue.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Sat, 7 Jun 2008 00:00:11 +0300

> Since IPv4 and IPv6 are so similar, the same problems will occur in
> both, and the same solution (in terms of the basic design and
> engineering) will work for both.

Noel,

you are certainly right that IPv4 and IPv6 are architecturally the
same.  But that doesn't necessarily mean that RRG's IPv4 and IPv6
solutions will be the same also.  Since many details in IPv4 and
IPv6 are different, so are the sets of "tools" you have available for
designing IPv4 vs. IPv6 solutions.  This may make separate solutions
for both IP versions preferable.

The above is part of the reasoning why, in previous emails, I
suggested that RRG should allow for separate IPv4/IPv6 solutions.

- Christian

---

From: Dan Jen <[email-masked]>
Date: Fri, 06 Jun 2008 14:07:09 -0700

Just out of curiosity...

I understand that we are thinking of a solution that works for the long
term.  So if someone comes up with a solution that isn't compatible with
ipv6, yet appears to be a long-term solution to the scalability problem,
why would we want to reject this?

I'm guessing we just want to have some constraints so that conversations
don't fly all over the place.  That's understandable, and I would
support that.

Dan Jen

---

From: "Tony Li" <[email-masked]>
Date: Fri, 6 Jun 2008 14:23:58 -0700

|I understand that we are thinking of a solution that works for the long
|term.  So if someone comes up with a solution that isn't 
|compatible with
|ipv6, yet appears to be a long-term solution to the 
|scalability problem,
|why would we want to reject this?
|
|I'm guessing we just want to have some constraints so that 
|conversations
|don't fly all over the place.  That's understandable, and I would
|support that.

Like it or not, IPv6 is the stated way forward for the IETF.  If someone
shows up with something wonderful that is incompatible with v6, it's well
beyond our chater to propose an alternative for v6.  Note that modifications
would be within our charter.

Yes, we are trying to bound the conversation and make some forward progress.
Pulling hen's teeth would be substantially easier.

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 6 Jun 2008 14:51:00 -0700

> suggested that RRG should allow for separate IPv4/IPv6 solutions.

There needs to be a very compelling reason to make the solutions  
different for v4 versus v6. We would be doing a disservice to the  
community to purposely make them different.

In fact, let me make a stronger statement. If they are different, that  
could be another barrier to getting IPv6 deployed.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 6 Jun 2008 14:53:41 -0700

> would be within our charter.

We have to create a balanced view. v4 is not more important than v6  
and v6 is not more important than v4. So I would state:

Like it or not, IPv4 is the stated way forward for the IETF.  If someone
shows up with something wonderful that is incompatible with v4, it's  
well
beyond our charter to propose an alternative for v4.  Note that  
modifications
would be within our charter.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Fri, 6 Jun 2008 15:34:21 -0700

|We have to create a balanced view. v4 is not more important than v6  
|and v6 is not more important than v4. So I would state:
|
|Like it or not, IPv4 is the stated way forward for the IETF.  
|If someone
|shows up with something wonderful that is incompatible with v4, it's  
|well
|beyond our charter to propose an alternative for v4.  Note that  
|modifications
|would be within our charter.

<co-chair>
Tweet.

I'm sorry, but this is verging on v4 vs. v6 bashing, and that's wholly
inappropriate here.
Not to mention irrelevant.
</co-chair>

Tony

---

From: "Tony Li" <[email-masked]>
Date: Fri, 6 Jun 2008 15:37:08 -0700

|> Our recommendation should be applicable to IPv6.  It may or may not
|> also apply to IPv4, but at the very least must provide a path forward
|> for IPv6.
|
|Would this allow for separate solutions for IPv4 and IPv6?  RRG
|shouldn't force itself to handle IPv4 with the same protocol that
|handles IPv6 IMO.

Separate solutions would seem to fall under the "may not also apply" case.

|But since your text talks about a "recommendation" and not a protocol,
|this may actually not be an issue.

Please recall that our charter is only to make a recommendation.

Tony

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 6 Jun 2008 15:48:59 -0700

> Not to mention irrelevant.

That was not my intent at all. I write IPv6 code every day.

Dino

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 7 Jun 2008 13:18:46 +0200

On 6 jun 2008, at 19:20, Scott Brim wrote:

>> Our recommended solution should be applicable to IPv6.  It may also  

I agree. Let me reword: if we can fix scalability for IPv6 and not for  
IPv4, that's not ideal but still a success. If we can fix scalability  
for IPv4 and not IPv6, that's a failure.

At current rates of deaggregation we can build routers with a FIB that  
can handle the entire IPv4 unicast space as /24s before we've used up  
and deaggregated the entire IPv4 unicast space as /24s.

> I think applicability to IPv4 is equally important.  First, it will  
> be years before there are more IPv6 packets than IPv4 packets --  
> longer than the time frame in which we must get our new technology  
> deployed -- and efficient control of IPv4 forwarding is important.

The vendors tell us we don't have an immediate problem.

> Second, the granularity of IPv4 allocations is very probably going  
> to go up dramatically in these final days, and that "state*rate"  
> load will not go away for a long time.

Network operators abhor a vacuum. So they'll come up with inter-domain  
routing practices that use up whatever the hardware and the protocols  
give them. But for obvious reasons, not much more than that.

I looked at the prefix length distributions between the respective RIR  
allocations and BGP announcements for both v4 and v6 recently. In v4,  
the correlation between allocations/assignments and advertisements is  
pretty much 1 for > /8, < /16. For longer prefixes there are (many)  
more announcements than allocations, culminating in a factor 4 (135k  
vs 35k) for /24.

http://www.bgpexpert.com/presentations/lacnic-ivb-ipv6-routingtable.pdf

Interestingly, at first I used the wrong data: I thought I had the  
most recent rouing table report but it was one from 2003. Although the  
number of /24 allocations/assignments back then wasn't all that much  
lower than now, the number of announcements was only half.

So what I'm saying is that the announcement of long prefixes seems to  
be an automomous process that happens mostly regardless of the  
assignment/allocation of new prefixes. This means it will continue  
after we run out of IPv4 space.

But I don't see much reason to expect that it will start going faster  
then. I don't see how the largest telcos in the world that use up  
addresses by the millions are going to scrape the net for thousands  
of /24s when then can no longer get a /12. It's just not cost effective.

Also note that 95% of all announcements is for 6% of the address  
space. When push comes to shove being able to reach 95% of the  
internet may not seem like a bad deal and suddenly a turn-of-the- 
century router can keep up again.

In addition, client/server works quite well with the clients on v6 and  
the servers on v4, even today. For peer-to-peer stuff this is a bit  
harder but with IETF work like ICE this is relatively easy to fix.

> In fact, let me make a stronger statement. If they are different,  
> that could be another barrier to getting IPv6 deployed.

If it's a good solution, it could be a "killer app" for v6...

Iljitsch

---

From: Christian Vogt <[email-masked]>
Date: Sat, 7 Jun 2008 17:48:19 +0300

> could be another barrier to getting IPv6 deployed.

Dino,

sure, we shouldn't separate the solutions without a reason. What I was
saying is that we shouldn't limit ourselves to solutions that fit both
IPv4 and IPv6.  Again, given that the solution space is different for
IPv4 and IPv6, we might find that separate solutions are better.

Moreover, given that the solution space for IPv6 is larger than that
for IPv4 -- perhaps even a true super-set --, making use of this
larger solution space by designing separate IPv4/v6 solutions will
likely make the IPv6 solution better.  This would help IPv6 getting
deployed, not hinder it.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Sat, 7 Jun 2008 17:49:18 +0300

Tony -

> Separate solutions would seem to fall under the "may not also apply"  

Yes, that makes sense.  I fully support the above statement then.

> Please recall that our charter is only to make a recommendation.

Sure, I'm aware.

- Christian

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 7 Jun 2008 20:26:07 -0700

> IPv4 and IPv6, we might find that separate solutions are better.

Well since I believe the problem is the same for both, it is likely a  
single solution is probable.

> for IPv4 -- perhaps even a true super-set --, making use of this

That is not clear at all. But I will say it could be easier to deploy  
a solution for IPv6 because 1) there is less of it deployed and 2) it  
could be deployed cleaner than what we have deployed for IPv4.

> likely make the IPv6 solution better.  This would help IPv6 getting

If you can have one scalability solution, then there is one thing for  
people to learn and one step to deploy, then both IPv4 and IPv6 can  
use it. Regardless if one or the other or both is deployed.

Dino

---

From: Peter Sherbin <[email-masked]>
Date: Sun, 8 Jun 2008 10:23:02 -0700 (PDT)

> Our recommendation should be applicable to IPv6...

What is the prime driver: a protocol or an architecture? Would it make sense to clarify the "applicable"?

Thanks,

Peter

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Jun 2008 11:03:25 +1200

Iljitsch,

> and deaggregated the entire IPv4 unicast space as /24s.

Wait a minute. Wouldn't the *entire* space put us well above 10 million
/24s? Are you saying that we can definitely build routers that could
handle say, 10 million NATted /24s, so that all small and medium
businesses can multihome?  That problem seems to be essentially
as hard as a network in which all small and medium businesses have
their own PI prefix for IPv6. So it seems that whatever the future
holds, we have the same fundamental problem. At the architectural
level, the absolute address length seems irrelevant. It's the
number of deaggregated prefixes that seems to matter.

>> than the time frame in which we must get our new technology deployed
>> -- and efficient control of IPv4 forwarding is important.
> 

And we don't for IPv6 either.

>> will not go away for a long time.
> 
> pretty much 1 for > /8, < /16. For longer prefixes there are (many) more
> announcements than allocations, culminating in a factor 4 (135k vs 35k)
> for /24.
> 
> Interestingly, at first I used the wrong data: I thought I had the most
> recent rouing table report but it was one from 2003. Although the number
> of /24 allocations/assignments back then wasn't all that much lower than
> now, the number of announcements was only half.
> 
> So what I'm saying is that the announcement of long prefixes seems to be
> an automomous process that happens mostly regardless of the
> assignment/allocation of new prefixes. This means it will continue after
> we run out of IPv4 space.
> 
> addresses by the millions are going to scrape the net for thousands of
> /24s when then can no longer get a /12. It's just not cost effective.

Maybe not, but if so, that is when they will start using IPv6
as a cheaper way to grow their business. And the number of prefixes
will grow just the same, regardless of the address length.

> 
> Also note that 95% of all announcements is for 6% of the address space.
> When push comes to shove being able to reach 95% of the internet may not
> seem like a bad deal and suddenly a turn-of-the-century router can keep
> up again.

Is it OK if only 95% of telephones can be called, too?

> harder but with IETF work like ICE this is relatively easy to fix.

Yes, but that's just part of any v4/v6 coexistence model. Why is
it relevant here?

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 9 Jun 2008 13:35:18 +0200

> /24s?

1 - 223 /8 - RFC 1918 and 127 = 14479104 /24s...

> Are you saying that we can definitely build routers that could
> businesses can multihome?

Not "definitely" but certainly with a reasonable level of confidence,  
yes. Vendors say they can to 2M now, this is only a factor 7 more,  
that's 2^3, Moore should take care of that in 5 years, so doing this  
within 10 years should be easy.

> It's the number of deaggregated prefixes that seems to matter.

Well the address length may have some iportance (radix tree for 128- 
bit values isn't much fun compared to 32 bits) but yes, the number of  
prefixes is the most important thing.

>> space.

> Is it OK if only 95% of telephones can be called, too?

If people in the 5% can renumber into the 95%, sure.

(BTW, I get the person that I want to talk to on the line WAY less  
often than 95% of the time already.)

> Yes, but that's just part of any v4/v6 coexistence model. Why is

Because if/when it's widely adopted, clients needing an address will  
no longer be a factor in the use of IPv4 addresses.

---

From: "Tony Li" <[email-masked]>
Date: Mon, 9 Jun 2008 08:01:53 -0700

|> Our recommendation should be applicable to IPv6...
|
|What is the prime driver: a protocol or an architecture? Would 
|it make sense to clarify the "applicable"?

Our charter is to recommend architecture.

Tony

---

From: "Tony Li" <[email-masked]>
Date: Mon, 9 Jun 2008 08:05:45 -0700

|> At current rates of deaggregation we can build routers with 
|a FIB that
|> can handle the entire IPv4 unicast space as /24s before we've used up
|> and deaggregated the entire IPv4 unicast space as /24s.
|
|Wait a minute. Wouldn't the *entire* space put us well above 10 million
|/24s? Are you saying that we can definitely build routers that could
|handle say, 10 million NATted /24s, so that all small and medium
|businesses can multihome?  

Definitely.  However, there would be some additional expense involved (and
latency in the product delivery).  Such products would require some
additional physical resources over what's being designed in today and would
require a separate development cycle.  There would also be an addition to
the cost structures of the products, which would undoubtedly be reflected in
pricing.

Tony

---

From: "Ross Callon" <[email-masked]>
Date: Mon, 9 Jun 2008 11:54:38 -0400

> within 10 years should be easy.

We might want to make a distinction here between:

1) What some (the most limited of the widely deployed) existing 
   equipment can do without any hardware upgrade
2) What other existing widely deployed equipment can do without any 
   hardware upgrade
3) What equipment being designed today will be able to do without 
   any significant chance in router architecture or cost (making 
   use of updated hardware capabilities that are in the works for 
   other commercial reasons)
4) What could be built in the next five to ten years if we were 
   willing to have the cost of some parts of the router increase 
   linearly with FIB size.

No one is talking about "4", for the simple reason that we don't have
to: "3" will handle the anticipated growth, with some room to spare. "4"
could *definitely* handle a lot more than 10 million routes if we needed
to. (But why would anyone build it unless it is needed?) "3" will get
close to 10 million /24 routes (within a factor of two one way or the
other, with details varying). 

I can see good reasons for taking on the type of thought that the RRG is
doing. Worrying about whether it will be possible to build new routers
to support currently anticipated future growth is *NOT* one of the good
reasons. 

Ross

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jun 2008 09:09:40 +1200

> apply to IPv4, but at the very least must provide a path forward for IPv6.

I'll buy this model, after the last 24 hours of discussion.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Mon, 9 Jun 2008 14:55:19 -0700

>> also

WFM.

Bob

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 9 Jun 2008 18:07:26 -0400

>> apply to IPv4, but at the very least must provide a path forward  

This take sounds good to me.

Regards
Marshall

---

From: "Tony Li" <[email-masked]>
Date: Fri, 13 Jun 2008 18:29:38 -0700

Folks,

Last week we did a consensus check on the following:

|Our recommendation should be applicable to IPv6.  It may or 
|may not also apply to IPv4, but at the very least must provide 
|a path forward for IPv6.

It's my judgement that we have rough consensus on this.  There is dissent,
notably from Robin and Bill, but overall, it seems that we have rough
consensus.

Tony

---

From: Scott Brim <[email-masked]>
Date: Fri, 13 Jun 2008 21:36:59 -0400

> notably from Robin and Bill, but overall, it seems that we have rough

I don't dissent with this single statement, given the context you put
it in back at the beginning when I asked about it.  It says nothing
about the importance of the IPv4 problems.  The rest of the discussion
was not really about this statement.

---

From: Lixia Zhang <[email-masked]>
Date: Thu, 19 Jun 2008 06:43:25 -0700

On Jun 18, 2008, at 4:08 PM, Vince Fuller wrote:
> Date: Wed, 18 Jun 2008 16:05:03 -0700
> From: Vince Fuller <[email-masked]>
> To: Tony Li <[email-masked]>
> Cc: 'rrg' <rrg@psgcom>
> Subject: Re: [RRG] Moving forward...
>
> FWIW, put me into the more-rough, non-consensus camp that thinks  
> providing a
> solution for IPv4 is a requirement.
>
> Speaking for myself only.
>
> 	--Vince

You are not in the non-consensus camp :-)
I had some private exchange with Tony on this issue, but let me put it  
in public to help the consensus gathering: I agree that the solution  
must work for IPv6, but at the same time,
- IPv4/v6 share the same architecture; the only major fundamental
   difference is their address space size.
- my notion of the RRG task is to develop an architectural
   solution to routing scalability.
- We should step up a level from looking specific versions of
   IP at this stage of solution development.  Our solution has to be
   an architectural change, and should work for either version.

Lixia

---

From: "William Herrin" <[email-masked]>
Date: Thu, 19 Jun 2008 09:48:47 -0400

Tony,

I counted:

9 for
3 accept with the reservation that the IPv4 and IPv6 solutions should
be identical
4 offering other reservations
3 against

That's a pretty weak consensus. Are you sure you want to roll forward
without seeking a statement that more than a minority can agree to
without reservations?

Personally, I've reached the view that there are three worthy avenues
of investigation, and we should be pursuing all three of them in
parallel:

1. The IPv6 variant (which may be but probably isn't compatible with IPv4)
2. The IPv4 variant (which is compatible with but likely suboptimal for IPv6)
3. The clean-slate variant which we could design if we weren't
constrained by IPv4 or IPv6.

Each is interesting in its own right, mild competition between the
three efforts will tend to improve all of them and IMO each is likely
to yield knowledge that proves useful to the other two but wouldn't
otherwise be discovered.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked] [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: "William Herrin" <[email-masked]>
Date: Thu, 19 Jun 2008 10:22:31 -0400

On Thu, Jun 19, 2008 at 9:43 AM, Lixia Zhang <[email-masked]> wrote:
> I had some private exchange with Tony on this issue, but let me put it in
> public to help the consensus gathering: I agree that the solution must work
> for IPv6, but at the same time,

Lixia,

There's a second fundamental difference: IPv6 is still relatively
malleable. We can make significant adjustments to the protocol
(significant relative to what's possible with IPv4) because there
isn't a large enough installed base to be harmed by it.

Those differences lead to a different solution tree. For example,
http://bill.herrin.us/network/ermpi6.html would be compatible with
deployed IPv6 from an address-management perspective and would slowly
become compatible with multihoming once changes to the IPv6 stack were
deployed to match.

Unfortunately, nothing down that likely superior solution tree is
compatible with IPv4.

Regards,
Bill Herrin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 19 Jun 2008 10:55:40 -0400

There are at least two dimensions in which the differences between v4 
and v6 may make a difference to what sorts of solutions are effective / 
deployable / definable / ...
1) The fact that the IPv6 header has lots of bits means that there are 
solutions that do not involve encapsulation or information loss which 
can be considered with v6 that do not apply to v4.
2) The fact that v6 is still, in practice, in very early stages means 
that there is more willingness to change the system to make it worth 
having.  And that folks are more willing to look at changes.

This does not mean that I want to ignore IPv4.  But it does mean that I 
think the differences may have an impact on the architectural approach 
we recommend.  And I would hate to see us declare that we will not 
consider any approach which can not leverage those differences.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 19 Jun 2008 08:59:54 -0700

> There are at least two dimensions in which the differences between  
> v4 and v6 may make a difference to what sorts of solutions are  
> effective / deployable / definable / ...
> 1) The fact that the IPv6 header has lots of bits means that there  
> are solutions that do not involve encapsulation or information loss  
> which can be considered with v6 that do not apply to v4.
> 2) The fact that v6 is still, in practice, in very early stages  
> means that there is more willingness to change the system to make it  
> worth having.  And that folks are more willing to look at changes.
>
> This does not mean that I want to ignore IPv4.  But it does mean  
> that I think the differences may have an impact on the architectural  
> approach we recommend.  And I would hate to see us declare that we  
> will not consider any approach which can not leverage those  
> differences.

Joel, since we are staying at the conceptual level, I think from an  
architecture point of view we can come up with one architecture for  
both address families. But I agree with you, at the engineering level  
there are different ways to achieve the architecture, where mechanisms  
can be  optimized for the specific address-family.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Thu, 19 Jun 2008 09:54:15 -0700

Hi Bill,

|I counted:
|
|9 for
|3 accept with the reservation that the IPv4 and IPv6 solutions should
|be identical
|4 offering other reservations
|3 against
|
|That's a pretty weak consensus. Are you sure you want to roll forward
|without seeking a statement that more than a minority can agree to
|without reservations?

I admit that it's rough consensus, for varying definitions of 'rough'.  ;-)

I wasn't trying to take a vote, just express my sense of where we stand.  If
it becomes critical at some point and folks feel that it's necessary, I'm
more than happy to put things to a formal vote.

Tony

---

From: "Tony Li" <[email-masked]>
Date: Thu, 19 Jun 2008 10:03:08 -0700

|There are at least two dimensions in which the differences between v4 
|and v6 may make a difference to what sorts of solutions are 
|effective / 
|deployable / definable / ...
|1) The fact that the IPv6 header has lots of bits means that there are 
|solutions that do not involve encapsulation or information loss which 
|can be considered with v6 that do not apply to v4.
|2) The fact that v6 is still, in practice, in very early stages means 
|that there is more willingness to change the system to make it worth 
|having.  And that folks are more willing to look at changes.
|
|This does not mean that I want to ignore IPv4.  But it does 
|mean that I 
|think the differences may have an impact on the architectural approach 
|we recommend.  And I would hate to see us declare that we will not 
|consider any approach which can not leverage those differences.

Agree.

Moreover, my goal here is to effect a substantive change in the basic
routing architecture, not just to band-aid the problem.  Whatever solution
that we come up with is going to have to last effectively indefinitely, so
it behooves us to do something that's clean.  IPv4 has now lasted 25 years.
It seems likely that if we do in fact make a shift to v6, then it would be
effectively forever or at least long enough to exceed the life span of
anyone currently on the mailing list.  I'd very much prefer that we left our
grandchildren something that we could all be proud of.

If we do find something that is both clean AND can be back-ported to v4, I
would definitely support that.

Tony

---

From: Scott Brim <[email-masked]>
Date: Thu, 19 Jun 2008 13:38:24 -0400

Agree.

Agree.

"Clean" as in: in accord with the design goals draft.

But Lixia is right.  At this point it shouldn't matter whether something 
can be put in a hop-by-hop header or not.  We don't need to be down at 
that level.  So v4 vs v6 shouldn't be an issue yet.

---

From: David R Oran <[email-masked]>
Date: Thu, 19 Jun 2008 13:46:25 -0400

On Jun 19, 2008, at 11:59 AM, Dino Farinacci wrote:

>> means that there is more willingness to change the system to make  
>> it worth having.  And that folks are more willing to look at changes.
>>
>> that I think the differences may have an impact on the  
>> architectural approach we recommend.  And I would hate to see us  
>> declare that we will not consider any approach which can not  
>> leverage those differences.
>
> both address families. But I agree with you, at the engineering  
> level there are different ways to achieve the architecture, where  
> mechanisms can be  optimized for the specific address-family.
>
Warning - blatantly personal reaction:

This exchange highlights for me why I simply can't process this  
distinction between the conceptual level and the engineering level.  
It's a near continuum in my thought processes...

Back to your regularly-scheduled program.

DaveO.

---

From: "William Herrin" <[email-masked]>
Date: Thu, 19 Jun 2008 14:08:59 -0400

On Thu, Jun 19, 2008 at 12:54 PM, Tony Li <[email-masked]> wrote:

> I wasn't trying to take a vote, just express my sense of where we stand.

Tony,

I appreciate what you're trying to accomplish here but I think you
improperly merged two consensus statements into one. Unless I'm badly
mistaken we only have consensus on one of them.

1. Any valid solution set must support IPv6.

2. A valid solution set may but is not required to support IPv4.

I suspect we have a strong consensus on point 1. The reservations,
hedging and outright rejection offered strongly suggest that we lack
consensus (rough or otherwise) on point 2.

There's a simple enough solution: take the two separated statements
and ask again.

Regards,
Bill Herrin

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 19 Jun 2008 11:37:15 -0700

> It's a near continuum in my thought processes...

I couldn't agree more Dave, but those are the constraints we are under.

Dino

---

From: "Tony Li" <[email-masked]>
Date: Thu, 19 Jun 2008 11:44:27 -0700

Scott,

|"Clean" as in: in accord with the design goals draft.

My version of 'clean' is much strong than just meeting the design goals.  It
also has to do with complexity, overhead, fit, and harmony.

Tony

---

From: Scott Brim <[email-masked]>
Date: Thu, 19 Jun 2008 14:49:32 -0400

> also has to do with complexity, overhead, fit, and harmony.

Could you write them up for the design goals?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jun 2008 10:22:46 +1200

On 2008-06-20 03:59, Dino Farinacci wrote:
>> and v6 may make a difference to what sorts of solutions are effective
>> / deployable / definable / ...
>> This does not mean that I want to ignore IPv4.  But it does mean that
>> I think the differences may have an impact on the architectural
>> will not consider any approach which can not leverage those differences.
> 
> architecture point of view we can come up with one architecture for both
> address families. But I agree with you, at the engineering level there
> are different ways to achieve the architecture, where mechanisms can be 
> optimized for the specific address-family.
> 

+1

On 2008-06-20 06:08, William Herrin wrote:
...
> consensus (rough or otherwise) on point 2.

The reason, if you're correct about point 2, is probably that
we have no certainty whether in the end-game for IPv4 address space,
the DFZ will deaggregate into a horrendous pre-CIDR-like swamp,
or whether it will remain aggregated due to double NAT (as
advocated by draft-shirasaki-isp-shared-addr). I'd say that if
we want to avoid the horrible future that draft would lead to,
we'd better have an RRG solution for IPv4, i.e. be ready for
large scale deaggregation.

    Brian

---

From: [email-masked] (Noel Chiappa)
Date: Thu, 19 Jun 2008 19:01:36 -0400 (EDT)

> From: Lixia Zhang <[email-masked]>

    > IPv4/v6 share the same architecture; the only major fundamental
    > [M]y notion of the RRG task is to develop an architectural
    > We should step up a level from looking specific versions of

One observation triggered by reading this: 99.2% of the discussion to date
has not been about a new routing (aka path-selection) architecture. Nowhere
have we been talking about the selection of paths. (Don't get me wrong, I'm
not throwing rocks here, I just want to make sure people are aware of this
point.)

Rather, discussion to date has been about how something new might be grafted
onto the side of the existing architecture, and in particular, about the
subset of that topic which is 'how we can escape the problem of the existing
overloaded semantics on IPv4/6 addresses'. I.e. how can we incrementally/
interoperably deploy a new namespace alongside the existing one.

I don't know for certain why this focus on this particular aspect of the
problem is happening: perhaps people want to get a decision on how to extend
the foundation extended before they start talking about how to the build
walls; or perhaps people think something like the existing path-selection
architecture (BGP, with all its warts) will be fine, if it has its own
namespace to play with; or perhaps people are just street-lighting. Dunno;
and no doubt different mixes of reasons apply to different people.

However, unless people do think that the existing BGP architecture is fine,
eventually we will have to talk about routing too, if we are to fulfil the
goal that Lixia laid out. I.e. what functionality the routing
(path-selection) system should/would have, how that system should/would be
broken up into subsystems, how the subsystems should/would communicate with
each other, what data they would need, how users would interact with it, etc,
etc, etc.

A long road lies ahead...

	Noel

---

From: David Conrad <[email-masked]>
Date: Fri, 20 Jun 2008 11:30:11 +0900

Hi,

> constrained by IPv4 or IPv6.

In a world of limited resources, which should be the priority?

Thanks,
-drc

---

From: "William Herrin" <[email-masked]>
Date: Thu, 19 Jun 2008 23:01:29 -0400

> In a world of limited resources, which should be the priority?

David,

The one that demonstrably impacts the largest installed customer base,
obviously.

But that's a false question. The limited resource is not manhours but
rather the creative input of the group's participants. Like with the
Manhattan Project, that creative input usually benefits from pursuing
multiple solution paths to completion.

Regards,
Bill Herrin

---

From: Stephen Sprunk <[email-masked]>
Date: Thu, 26 Jun 2008 10:34:48 -0500

> shouldn't force itself to handle IPv4 with the same protocol that

I would strongly prefer a solution that can handle the EID/RLOC pairs of 
v6/v6, v6/v4, and v4/v6.  If it also handles v4/v4 as a side effect, 
that may be useful or it may not.

S

---

From: David Conrad <[email-masked]>
Date: Thu, 26 Jun 2008 09:05:16 -0700

Bill,

On Jun 19, 2008, at 8:01 PM, William Herrin wrote:
>>> 2. The IPv4 variant (which is compatible with but likely  
>>> suboptimal for
>>> IPv6)

This isn't obvious to me.

In the ideal world, we could come up with a solution that treats the  
end point identifier as a variable length opaque bag of bits and Do  
the Right Thing with it.

However, assuming we're not in the ideal world, there has to be some  
prioritization.  The installed base is using a protocol that cannot  
meet the fundamental requirement of the Internet, that of providing  
ubiquitous connectivity.  IPv4 augmented with NAT may be able to meet  
that requirement, but at some additional operational cost that many  
believe to be prohibitive.  As such, it one must choose, it would seem  
obvious to me that you choose to modify the protocol that has the best  
chance of meeting long term requirements.

However, with that said, the basic question was whether or not there  
was (rough) consensus.  It would appear not.

Regards,
-drc

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 Jul 2008 16:19:21 +0300

Tony,

> notably from Robin and Bill, but overall, it seems that we have rough
I know I am late with my mail, but I just wanted to say that I also 
support this consensus.

(I also agree with some of the views posted in the thread from Joel and 
others on the potential detail-level differences between v4 and v6 that 
may result in different engineering solutions.)

Jari