Re: [rrg] draft-narten-radir-problem-statement-05.txt

2010-03-02 Thread Flinck, Hannu (NSN - FI/Espoo)
Hello Heiner,

Here are some data bits from the compact routing view:

Shortest path routing is incompressible (lower = upper bound): Omega(n
log n).
There are a set of compact routing universal algorithms that
compresses routing table to O(n^1/2) (upper bound) with the cost of
increasing the worst case stretch to 3 [1,2] . Universal in this context
means that nothing is assumed about the graph topology. If you can
assume, such as power law distribution for the Internet there are a
scheme offering routing table scaling of O[(log n)^2][3]. (here log is
log base 2).

All of them reduce the routing table size as you can see.

Now, would these schemes be applied to the core BGP to reduce the table
size. I do not think so. That's because the BGP works, and fixing
something that works is not practical at least cost wise. But these
schemes could be used for to limit the growth in the routing system that
routes based on the end point identities. Please see my proposal on that
part, if you care.

By the way, I would be very much interested to read the TARA
specification that you have been referring several years already.

Best regards
Hannu

[1] Krioukov D., kc claffy, K. Fall, and A. Brady. On compact
routing
for the Internet. ACM SIGCOMM Computer Communication
Review (CCR), 37(3), 2007.

[2] I. Abraham, C. Gavoille, A. Goldberg, D. Malkhi. Routing in
Networks with Low Doubling Dimensions, Proceedings of the 26th IEEE
International Conference on Distributed Computing Systems, p.75, July
04-07, 2006  

[3] S. Carmi, R. Cohen, and D. Dolev. Searching complex networks
efficiently with minimal information. Europhysics Letters, 74(6), 2006.


-Original Message-
From: rrg-boun...@irtf.org [mailto:rrg-boun...@irtf.org] On 
Behalf Of ext Brian E Carpenter
Sent: Tuesday, March 02, 2010 02:06
To: heinerhum...@aol.com
Cc: nar...@us.ibm.com; rrg@irtf.org
Subject: Re: [rrg] draft-narten-radir-problem-statement-05.txt

On 2010-03-02 12:36, heinerhum...@aol.com wrote:
...
 Statement:  Neither LISP nor any of all the other submitted  
solutions 
 do reduce the number of routes
 - not even by the number 1.

IMHO the issue is not to reduce the number of routes but to 
limit their growth. At the moment they seem to be limited 
loosely like the square root of the size of the Internet, and 
our goal is presumably to limit them more strongly than that 
-- log(N) would be lovely.

There is a lot of speculation in this, but since the pressure 
towards route de-aggregation seems to come mainly from PI 
addressing and the demand for multihoming, a solution that 
enables PA aggregation seems certain to limit growth, compared 
to doing nothing. There are a number of solutions in the list 
that appear to do this.

Brian

___
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg

___
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg


Re: [rrg] draft-narten-radir-problem-statement-05.txt

2010-03-02 Thread HeinerHummel
In einer eMail vom 02.03.2010 13:19:47 Westeuropäische Normalzeit schreibt  
hannu.fli...@nsn.com:

Hello  Heiner,

Here are some data bits from the compact routing  view:

Shortest path routing is incompressible (lower = upper bound):  Omega(n
log n).
yes.


There are a set of compact routing universal algorithms  that
compresses routing table to O(n^1/2) (upper bound) with the cost  of
increasing the worst case stretch to 3 [1,2] . 
Yuk. I am in favor of inflating (rather than  compressing) the (TARA-) 
routing tables (with multiple spares) so that next  hop lookup can be done by 
either one or three table offsets.
Wrt  stretch: This term makes only sense, if your solution has to live  
with stretch 3  and might be happy by avoiding stretch 17.  But  we should 
definitely shoot for stretch 1, i.e. have  a lot of  shortest paths and ,yes, 
also a plenty of detours. 
 

Universal in this context
means that nothing is assumed about  the graph topology. If you can
assume, such as power law distribution for  the Internet there are a
scheme offering routing table scaling of O[(log  n)^2][3]. (here log is
log base 2).

All of them reduce the routing  table size as you can see.
See above. I can afford to inflate them.



Now, would these schemes be applied to the core BGP to  reduce the table
size. I do not think so. That's because the BGP works, and  fixing
something that works is not practical at least cost wise. But  these
schemes could be used for to limit the growth in the routing system  that
routes based on the end point identities. Please see my proposal on  that
part, if you care.

It is not only TARA, but with TARA and with quite a few more routing  
algorithms, routing technology can soar to a new level of  perfection. A  whole 
generation of young students could spin the wheel of progress for  some 
decades just as we did, based on the current but awfully  bad  paradigms, for 
quite a while.
 
Heiner
 

By the  way, I would be very much interested to read the TARA
specification that  you have been referring several years already.

Best regards
Hannu

[1]  Krioukov D., kc claffy, K. Fall, and A. Brady. On compact
routing
for  the Internet. ACM SIGCOMM Computer Communication
Review (CCR), 37(3),  2007.

[2] I. Abraham, C. Gavoille, A. Goldberg, D. Malkhi. Routing  in
Networks with Low Doubling Dimensions, Proceedings of the 26th  IEEE
International Conference on Distributed Computing Systems, p.75,  July
04-07, 2006  

[3] S. Carmi, R. Cohen, and D. Dolev.  Searching complex networks
efficiently with minimal information.  Europhysics Letters, 74(6), 2006.


-Original  Message-
From: rrg-boun...@irtf.org [mailto:rrg-boun...@irtf.org]  On 
Behalf Of ext Brian E Carpenter
Sent: Tuesday, March 02,  2010 02:06
To: heinerhum...@aol.com
Cc: nar...@us.ibm.com;  rrg@irtf.org
Subject: Re: [rrg]  draft-narten-radir-problem-statement-05.txt

On 2010-03-02  12:36, heinerhum...@aol.com wrote:
...
 Statement:   Neither LISP nor any of all the other submitted  
solutions  
 do reduce the number of routes
 - not even by the  number 1.

IMHO the issue is not to reduce the number of routes  but to 
limit their growth. At the moment they seem to be limited  
loosely like the square root of the size of the Internet, and  
our goal is presumably to limit them more strongly than that  
-- log(N) would be lovely.

There is a lot of  speculation in this, but since the pressure 
towards route  de-aggregation seems to come mainly from PI 
addressing and the demand  for multihoming, a solution that 
enables PA aggregation seems certain  to limit growth, compared 
to doing nothing. There are a number of  solutions in the list 
that appear to do this.

Brian

___
rrg  mailing  list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg


 
___
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg


Re: [rrg] draft-narten-radir-problem-statement-05.txt

2010-02-25 Thread Joel M. Halpern
Thank you for responding Thomas.  I don't think what you propose is 
sufficient.  (More after your comments, for context.)


Thomas Narten wrote:

Hi Joel.

Thanks for the comments.


Thomas, one major and some minor comments on the document.


The discussion of IPv6 routing table size in section 4.6 seems 
misleading.  The discussion seems to have no component to represent the 
present and increasing demand for PI addresses in order to support 
multi-homing and ease of renumbering.  If we do not have a routing 
architecture and system which addresses those pressures, and if we do 
not manage to keep in place an artificial barrier to such PI 
assignments, the size of the tables will grow dramatically.  Some 
stimates place the expected number of multiohomed enterprises in the 
ballpark of 10,000,000.  That would represent a significant growth in 
the control plane, the RIB, and the FIB.


This section was intended to simply point out that dual stack adds
even more routes, in the sense that one will need both IPv4 and IPv6
route to the same destination. That only further increases the overall
number of entries a router deals with.

It goes without saying (and looking back, the document doesn't say
this) that all the  pressures that apply to IPv4 routing, apply pretty
much equally to IPv6.

Seems to me, that the best way to deal with that is to add a new
paragraph (perhaps in the introduction) that calls this out
explicitely. I.e., something like:

   Most of this document does not distinguish between IPv4 and
   IPv6. The overall routing archtecture for the two protocols is the
   same. Consequently, most of the issues in this document apply
   equally to IPv4 and IPv6. Any behavior that places pressure on IPv4
   routing is likely to also exert the same pressure on IPv6.
   Deployment of IPv6 will not lessen these pressures in most cases.



What you propose to add is good.  But, the text in 4.6 as written claims 
It is possible to extrapolate what the size of the IPv6 routing table 
would be if wide spread adoption of IPv6 occurred...  Unfortunately, 
the extrapolation that then takes place assumes that the same factors 
that currently constrain IPv4 sizes would constrain IPvb6 sizes, and 
that seems extremely unlikely.  Hence, this extrapolation is very 
optimistic, and misleading to the reader.


Yours,
Joel

___
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg


Re: [rrg] draft-narten-radir-problem-statement-05.txt

2010-02-25 Thread Thomas Narten
 What you propose to add is good.  But, the text in 4.6 as written claims 
 It is possible to extrapolate what the size of the IPv6 routing table 
 would be if wide spread adoption of IPv6 occurred...

Ah. Is your issue more narrow in the sense that this statement is
misleading?

The extrapolation is intended for today not for next year or ten
years from now.

You must be assuming that the exising pressures that contribute to
problems will get worse (I tend to agree!). But, that doesn't really
have anything to do with IPv6. I.e., IPv6 doesn't make those pressures
stronger or lesser.  They will also get worse with IPv4.

 the extrapolation that then takes place assumes that the same factors 
 that currently constrain IPv4 sizes would constrain IPvb6 sizes, and 
 that seems extremely unlikely.  Hence, this extrapolation is very 
 optimistic, and misleading to the reader.

How about if I change the statement as follows:

OLD:

   It is possible to extrapolate what the size of the IPv6 Internet
   routing table would be if widespread IPv6 adoption occurred, from the
   current IPv4 Internet routing table.  

NEW:

   It is possible to extrapolate what the size of the IPv6 Internet
   routing table might look like today, from the current IPv4 Internet
   routing table, if widespread IPv6 adoption were to occur
   instantaneously,

Then, at the end of the paragraph add something like:

   Of course, this estimate is based on a current snapshot of IPv4
   routing activity. Unless the pressures described elsewhere in this
   document are reduced, the actual table size would be larger.

Would that address your concern?   

Thomas   
___
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg


Re: [rrg] draft-narten-radir-problem-statement-05.txt

2010-02-25 Thread Brian E Carpenter
On 2010-02-26 09:40, Joel M. Halpern wrote:
...

Most of this document does not distinguish between IPv4 and
IPv6. The overall routing archtecture for the two protocols is the
same. Consequently, most of the issues in this document apply
equally to IPv4 and IPv6. Any behavior that places pressure on IPv4
routing is likely to also exert the same pressure on IPv6.
Deployment of IPv6 will not lessen these pressures in most cases.

 
 What you propose to add is good.  But, the text in 4.6 as written claims
 It is possible to extrapolate what the size of the IPv6 routing table
 would be if wide spread adoption of IPv6 occurred...  Unfortunately,
 the extrapolation that then takes place assumes that the same factors
 that currently constrain IPv4 sizes would constrain IPvb6 sizes, and
 that seems extremely unlikely.  Hence, this extrapolation is very
 optimistic, and misleading to the reader.

Joel, as you know, it isn't the length of the announced prefixes
that really matters, but the number of non-aggregated prefixes.
So the question is, what constrains the growth in that number?

That is of course very debatable, and there is a lot of research
literature about it. If current trends persist, for example,
you can conclude that a network of 10 billion hosts would
generate just over one million BGP4 routes.
(That is making a scientifically unjustified extrapolation
of the graphs in my CCR paper). But if the rate of multihoming
increases by a factor ten, and if multihoming continues to
require de-aggregation, we'd get ~10 million routes in BGP.
Numbers beyond that imply a much bigger deviation from current
practice than seems likely to me, since it's clear that the
majority of mobility needs will be met using captive-customer
addresses that are intrinsically PA.

My conclusion is that we can hope for 1 million routes but
should have a solution for 10 million. I don't think there is
anything in the data or technology that tells us we will
need a solution for 100 million or more.

All IMHO of course.

Thomas just wrote:

 NEW:
 
It is possible to extrapolate what the size of the IPv6 Internet
routing table might look like today, from the current IPv4 Internet
routing table, if widespread IPv6 adoption were to occur
instantaneously,
 
 Then, at the end of the paragraph add something like:
 
Of course, this estimate is based on a current snapshot of IPv4
routing activity. Unless the pressures described elsewhere in this
document are reduced, the actual table size would be larger.

I don't think that quite covers the very reasonable speculation
that the Internet will grow to around ten billion publicly-
addressable hosts under IPv6, and that this is part of the
problem. So I think we need to be clear that significantly
larger numbers are in our future.

Brian
___
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg


Re: [rrg] draft-narten-radir-problem-statement-05.txt

2010-02-25 Thread Joel M. Halpern
Yes, thank you.  That would address my concern.  I was reading 
extrapolate ... would look like in a broader sense than you intended.

Yours,
Joel

Thomas Narten wrote:
What you propose to add is good.  But, the text in 4.6 as written claims 
It is possible to extrapolate what the size of the IPv6 routing table 
would be if wide spread adoption of IPv6 occurred...


Ah. Is your issue more narrow in the sense that this statement is
misleading?

The extrapolation is intended for today not for next year or ten
years from now.

You must be assuming that the exising pressures that contribute to
problems will get worse (I tend to agree!). But, that doesn't really
have anything to do with IPv6. I.e., IPv6 doesn't make those pressures
stronger or lesser.  They will also get worse with IPv4.

the extrapolation that then takes place assumes that the same factors 
that currently constrain IPv4 sizes would constrain IPvb6 sizes, and 
that seems extremely unlikely.  Hence, this extrapolation is very 
optimistic, and misleading to the reader.


How about if I change the statement as follows:

OLD:

   It is possible to extrapolate what the size of the IPv6 Internet
   routing table would be if widespread IPv6 adoption occurred, from the
   current IPv4 Internet routing table.  


NEW:

   It is possible to extrapolate what the size of the IPv6 Internet
   routing table might look like today, from the current IPv4 Internet
   routing table, if widespread IPv6 adoption were to occur
   instantaneously,

Then, at the end of the paragraph add something like:

   Of course, this estimate is based on a current snapshot of IPv4
   routing activity. Unless the pressures described elsewhere in this
   document are reduced, the actual table size would be larger.

Would that address your concern?   

Thomas   


___
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg


Re: [rrg] draft-narten-radir-problem-statement-05.txt

2010-02-25 Thread Noel Chiappa
 From: Brian E Carpenter brian.e.carpen...@gmail.com

 I don't think there is anything in the data or technology that tells us
 we will need a solution for 100 million or more.

I wouldn't believe any predictions - we just don't know enough (e.g. about
changing usage models) to make our long-term models worth a darn.

Noel
___
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg


Re: [rrg] draft-narten-radir-problem-statement-05.txt

2010-02-24 Thread Thomas Narten
Hi Joel.

Thanks for the comments.

 Thomas, one major and some minor comments on the document.

 The discussion of IPv6 routing table size in section 4.6 seems 
 misleading.  The discussion seems to have no component to represent the 
 present and increasing demand for PI addresses in order to support 
 multi-homing and ease of renumbering.  If we do not have a routing 
 architecture and system which addresses those pressures, and if we do 
 not manage to keep in place an artificial barrier to such PI 
 assignments, the size of the tables will grow dramatically.  Some 
 stimates place the expected number of multiohomed enterprises in the 
 ballpark of 10,000,000.  That would represent a significant growth in 
 the control plane, the RIB, and the FIB.

This section was intended to simply point out that dual stack adds
even more routes, in the sense that one will need both IPv4 and IPv6
route to the same destination. That only further increases the overall
number of entries a router deals with.

It goes without saying (and looking back, the document doesn't say
this) that all the  pressures that apply to IPv4 routing, apply pretty
much equally to IPv6.

Seems to me, that the best way to deal with that is to add a new
paragraph (perhaps in the introduction) that calls this out
explicitely. I.e., something like:

   Most of this document does not distinguish between IPv4 and
   IPv6. The overall routing archtecture for the two protocols is the
   same. Consequently, most of the issues in this document apply
   equally to IPv4 and IPv6. Any behavior that places pressure on IPv4
   routing is likely to also exert the same pressure on IPv6.
   Deployment of IPv6 will not lessen these pressures in most cases.

 Section 3.3 is titled Alignment of Incentives.  It then begins with a 
 partial description of the pressures that Multihoming and Traffic 
 Engineering put on the system.
 It would seem that the document would be clearer if there were a section 
 describing the need to support multihoming and traffic engineering in 
 general (leaving the details for section 4 probably), and the fact that 
 these tend to produce growth in all the dimensions cited earlier.  That 
 could then be followed by section 3.3 with something similar to the 
 current second paragraph, which is actually about the Alignment of 
 Incentives.
 It would then seem sensible to include a paragraph about the need for 
 any mechanisms for improvement to have to property that the costs and 
 incentives for deploying the improvement are aligned.  (This appears in 
 the summary in section 6, but needs to be explicitly stated earlier in 
 the document.)

Let me think about this. I think I agree that the section would
benefit from some restructuring.

 Would it make sense to include in section 4.3 (End Site Renumbering) to 
 observation that this problem has also driven some NAT deployments? 
 (No, that is not a route scaling problem, but it reminds the reader of 
 an indirect cost of not solving these problems in an effective
 fashion.)

I guess I'm on the fence on this one. The goal of this document was to
describe the problems surrounding route scaling. So far, we have tried
hard not to add stuff that isn't directly related especially if people
might have strong views on the topic. In fairness, if we were going to
mention NAT, we'd have to point out that it has also helped relieve
pressure on the routing system -- i.e., there is a benefit.

 Should we at least acknowledge in section 5 that our habit of addressing 
 any and all problems with BGP extensions puts pressure on the control 
 plane?  (It may be that this component is manageable, but I wonder.) 
 Each of these features have been put in for very good reasons, but RFC 
 2547 VPNs, Flow-Routes for black-holing DDOS, and add-path routes to 
 allow use of multiple parallel routes, are all examples of features wew 
 have or are putting in the system that increase the pressure on the 
 Control Plane.  [Note, I am not saying that these are wrong choices. 
 They may well be correct choices, and BGP may well be the right place to 
 address these needs.  But we should recognize that this puts pressure on 
 the system.]

Given yours and Danny's comment on this, how about something like:

  BGP is the routing control plane protocol in use today. Because
  of its ubiquity and centrality to routing, it is also a natural
  place to add features that enhance routing functionality, some
  of which may not be strictly necessary to support DFZ routing
  (e.g., RFC 2547 VPNs). The use of such extensions also place
  additional pressures on the routing control plane as they must
  be sent, received, processed, etc. along with other routing
  updates.

Thomas  
___
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg


Re: [rrg] draft-narten-radir-problem-statement-05.txt

2010-02-24 Thread Thomas Narten
Hi Robin.

I've looked at some of the references and older messages, but it's not
clear to me what action item you want me to make. Do you have specific
concerns with the accuracy of our document? etc? It would be much more
helpful if you can point out specific wording or sections that you
feel are not right - and explain why.

 Section 3.3 states there are millions of potential end sites which
 would benefit from being able to multihome.  Brian Carpenter and I
 recently, independently, nominated 10 million as a rough upper limit
 on the number of non-mobile network which want or need portability,
 multihoming and/or TE (though perhaps Brian didn't mention
 portability.  My reasoning was roughly that with human population
 of 10 billion, there will probably be only one organisation per 1000
 people (mainly small companies, but also schools and other
 organisations) which have sufficient need of portability or
 multihoming to get edge space in a CES system and to get the two or
 more physical links from two or more ISP's services as needed for
 multihoming.

I don't know that I agree with this actually. In today's world of
DSL/Cable/soon-to-be ubiquitous wireless, I could imagine every home
using multiple ISPs. Won't those users want multihoming to work for
them?

But in any case, I don't know that  our document needs to take a stand
on any one particular number.

 I think the Problem Statement's references to 4.3. End Site
 Renumbering and to certain extent to 4.4. Acquisitions and
 Mergers could be improved by reference to address space
 portability.  The word portability does not appear in the
 Statement, and while I think it makes some people's teeth itch, I
 think it should be mentioned.

IMO, there is an important and subtle difference between portability
and renumbering hurts bad. They are not the same thing.

Portability is only wanted because that is the primary solution for
avoiding the pain of renumbering (other than NAT).

And portability also says (to me) something about individual prefixes
going into the DFZ, which is not really what people necessarily
actually care about (or want) when they want portability. They want
to be able to switch providers without renumbering. So I think it is
more accurate to focus on that as being the true underlying issue.

 The problems mentioned in these sections arguably only exist because
 only PI space is portable and that when splitting even this
 portable space into two separately advertised PI prefixes is
 possible, this contributes to the routing scaling problem.

Section 4.2 on multihoming pretty clearly points out that PI vs. PA is
not the issue w.r.t. causing problems in the case of multihoming. You
can multihome with PA space, but you get the same bad properties.

 Core-Edge Separation architectures provide a new subset of the global
 unicast address space which is portable in a scalable manner, and
 which can be split up much more finely than the /24 limit which
 applies to conventional PI prefixes.

 So I think it would be reasonable to describe a key part of the
 routing scaling problem as being due to the lack of portability for
 any scalable form of address space in the current system.

I am not convinced that this is an accurate statement.

Thomas
___
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg


Re: [rrg] draft-narten-radir-problem-statement-05.txt

2010-02-18 Thread Danny McPherson

On Feb 17, 2010, at 6:16 PM, Joel M. Halpern wrote:

 Should we at least acknowledge in section 5 that our habit of addressing 
 any and all problems with BGP extensions puts pressure on the control 
 plane?  (It may be that this component is manageable, but I wonder.) 
 Each of these features have been put in for very good reasons, but RFC 
 2547 VPNs, Flow-Routes for black-holing DDOS, and add-path routes to 
 allow use of multiple parallel routes, are all examples of features wew 
 have or are putting in the system that increase the pressure on the 
 Control Plane.

I've certainly echoed this sentiment many times now, so I agree 
Joel.  

I do have one clarification.  While they do introduce traditional control
and data plane overhead like any other BGP route, the DDoS countermeasures 
(i.e, BGP-based destination or uRPF/source-based blackhole routing) that 
are deployed today with BGP require no new features or attributes, they 
use only existing machinery - unlike flow spec and all the other stuff you 
mention above.

-danny
___
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg


Re: [rrg] draft-narten-radir-problem-statement-05.txt

2010-02-17 Thread Joel M. Halpern

Thomas, one major and some minor comments on the document.

The discussion of IPv6 routing table size in section 4.6 seems 
misleading.  The discussion seems to have no component to represent the 
present and increasing demand for PI addresses in order to support 
multi-homing and ease of renumbering.  If we do not have a routing 
architecture and system which addresses those pressures, and if we do 
not manage to keep in place an artificial barrier to such PI 
assignments, the size of the tables will grow dramatically.  Some 
stimates place the expected number of multiohomed enterprises in the 
ballpark of 10,000,000.  That would represent a significant growth in 
the control plane, the RIB, and the FIB.



Section 3.3 is titled Alignment of Incentives.  It then begins with a 
partial description of the pressures that Multihoming and Traffic 
Engineering put on the system.
It would seem that the document would be clearer if there were a section 
describing the need to support multihoming and traffic engineering in 
general (leaving the details for section 4 probably), and the fact that 
these tend to produce growth in all the dimensions cited earlier.  That 
could then be followed by section 3.3 with something similar to the 
current second paragraph, which is actually about the Alignment of 
Incentives.
It would then seem sensible to include a paragraph about the need for 
any mechanisms for improvement to have to property that the costs and 
incentives for deploying the improvement are aligned.  (This appears in 
the summary in section 6, but needs to be explicitly stated earlier in 
the document.)


Would it make sense to include in section 4.3 (End Site Renumbering) to 
observation that this problem has also driven some NAT deployments? 
(No, that is not a route scaling problem, but it reminds the reader of 
an indirect cost of not solving these problems in an effective fashion.)


Should we at least acknowledge in section 5 that our habit of addressing 
any and all problems with BGP extensions puts pressure on the control 
plane?  (It may be that this component is manageable, but I wonder.) 
Each of these features have been put in for very good reasons, but RFC 
2547 VPNs, Flow-Routes for black-holing DDOS, and add-path routes to 
allow use of multiple parallel routes, are all examples of features wew 
have or are putting in the system that increase the pressure on the 
Control Plane.  [Note, I am not saying that these are wrong choices. 
They may well be correct choices, and BGP may well be the right place to 
address these needs.  But we should recognize that this puts pressure on 
the system.]


Yours,
Joel M. Halpern

Thomas Narten wrote:

Hi.

With the recent thread on route scaling, now might be a good time for
folk on this list to have a fresh look at the route scaling problem
document below. This was put together by the Routing  Addressing
Directorate (http://wiki.tools.ietf.org/group/radir/) and is a joint
effort by all of its members.

The document has been sitting for a while, but we are now looking at
it again with the goal of getting it published as an Informational
RFC. In order to do that, we really need folk to review it and either
point out its shortcomings, or indicate that it's a useful document to
publish as is.

Thanks!


A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title   : On the Scalability of Internet Routing
Author(s)   : T. Narten
Filename: draft-narten-radir-problem-statement-05.txt
Pages   : 25
Date: 2010-02-17

There has been much discussion over the last years about the overall
scalability of the Internet routing system.  Some have argued that
the resources required to maintain routing tables in the core of the
Internet are growing faster than available technology will be able to
keep up.  Others disagree with that assessment.  This document
attempts to describe the factors that are placing pressure on the
routing system and the growth trends behind those factors.

___
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg


___
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg