Re: Weekly Routing Table Report

[Masataka Ohta]

John Kristoff wrote:


If you can't accept the following principle of the End to End
argument:


I think it is better to stick with what the paper refers to them e2e as,
an argument. The e2e paper is by far one of the closest things we
have to network canon and its reasoning is exceptionally simple and
compelling.  Yet, these are arguments, not laws.


Proof of the argument seems to be easy, see slide 11 of


http://www.ocw.titech.ac.jp/index.php?module=General=DownLoad=201904901-2662-0-35.pdf=cal=201904901


Even the original
authors have revisited and questioned the original ideas.


Extension of the argument to intermediate systems (to make the
argument directly applicable to protocols used within a network
such as routing protocols) and modern layering (the original
paper is skeptical to layering stating "it is fashionable these
days to talk about layered communication protocols" obviously
because OSI layering popular at that time is terrible) should
be useful.


Note, I'm not agreeing or disagreeing with any particular position
about multihoming in this thread,


Can you agree that, by applying the argument to function of
multihoming, we can get the following:

multihoming can completely and correctly be implemented
only with the knowledge and help of the application
standing at the end points of the communication system.
Therefore, providing multihoming as a feature of the
communication system itself is not possible.

then, the constructive question to ask is:

with the knowledge and help of the application standing
at the end points of the communication system, can
multihoming completely and correctly be implemented?

Once the question is asked, it is not very difficult to
construct a multihoming architecture to show the answer is "yes".

With such questions, the principle is very powerful tool to know
the right direction to perform research.

> just trying to argue that the e2e

paper is a lot more nuanced than is often presented in debates
especially since it has often been used to support opposing views.  :-)


The most serious problem with such debates is that people just
do not read the original paper:


http://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf

and have their own random definitions on the principle, which
makes the debates completely meaningless.

There are a lot of proofs saying the principle is invalid, using
their own definitions of the principle.

Masataka Ohta

Re: Weekly Routing Table Report

[John Kristoff]

On Sat, 31 Aug 2019 10:35:39 +
Masataka Ohta  wrote:

> If you can't accept the following principle of the End to End
> argument:

I think it is better to stick with what the paper refers to them e2e as,
an argument. The e2e paper is by far one of the closest things we
have to network canon and its reasoning is exceptionally simple and
compelling.  Yet, these are arguments, not laws.  Even the original
authors have revisited and questioned the original ideas.

The paper also says something about needing a great deal of system
implementation detail to intelligently make the choice of where to
place functions.  I like pointing that out, because it seems people
often miss this part in the paper where the only form of the word
intelligence is ever used in the paper.

Note, I'm not agreeing or disagreeing with any particular position
about multihoming in this thread, just trying to argue that the e2e
paper is a lot more nuanced than is often presented in debates
especially since it has often been used to support opposing views.  :-)

John

Re: Weekly Routing Table Report

[howard stearn]

Did we all forget the size of the IPv6 table is nearing a milestone number
in the DFZ? ;)

> It is a 3-day weekend in the US. A good time to pause for a few minutes
and consider what all of us accomplished together.
> Pat yourselves on the back, raise a glass or whatever your personal
traditions are, and bask in the glory of a job well done.
Patrick W. Gilmore
(Okay pat the back of your local network engineer if you forgot.)
Aclamaciones, Cheers, À votre santé!

> Nowadays boxes can easily take 5x the current 768 in
> tcam and in control-plane -only sky is the limit, so for example there's
no
> need for any clever RR infrastructure designs anymore to hold all the
routes
> in your AS control-plane.
>
adamv0025


If you have an older router that can only handle x number of routes in TCAM
less than the current number of routes; what software are you using to keep
it default free?
Or if the sky is really the limit, sell me your most or least expensive
Tbps capable TCAM that will hold a routing table of 3M+ routes IPv4 and
another 3M+ IPv6 without gimmicks or stipulations. (Low or high number of
interfaces, small or god-sized box.)
Let me know why you like what you have, or what you want to have.

Be thankful for your network.

What's in your rack?

Good Luck

On Sun, Sep 1, 2019 at 11:46 PM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Scott Weeks wrote:
>
> > Yes, my apologies for no reference.  Further, I have no URL to
> > point to as I read the book. (actual book; no e-something)
> >
> > Here's something:  http://pouzinsociety.org
>
> as I can't find open access papers or something like that there,
> let me stick to wikipedia.
>
> > Like the book, in the Wikipedia article you have to get through
> > or skip the first part.  In the book, that's the first 5 or so
> > chapters.  He just describes why, in his opinion, previous things
> > have failed and the way he does it turns a lot of folks off.
>
> Another major misunderstanding of him is that he is not aware that
> domain name with MX is application name and there are proposals
> (though unnecessarily complicated) such as SRV to cover other
> applications beyond SMTP. With SRV, non-default port numbers do not
> have to be specified in URLs.
>
> So, we already have application names of domain names and mapping
> mechanism between names and addresses/port_numers of DNS.
> > E2E (end-to-end principle) is not relevant
>
> That someone can not recognize relevance between something and the
> E2E principle does not mean much.
> > IPv6 is/was a waste of time
>
> True, but, the reason is because IPv4 Internet with DNS, TCP
> and NAT is good enough.
>
> That TCP identifies connections only by single source and destination
> addresses is certainly a problem. But, the least painful solution
> is to extend TCP to be able to identify connections by multiple
> addresses.
>
> Properly designed NAT can save IP addresses a lot still keeping the
> E2E transparency.
>
> > The RINA's fundamental principles are that computer
> > networking is just Inter-Process Communication or IPC,
>
> That is a too much computer centric view not very
> applicable to communications involving human beings,
> where the E2E argument must often be applied to human
> beings (true end) behind applications (tentative end
> in a computer).
>
> Masataka Ohta
>

Re: Weekly Routing Table Report

[Stephen Satchell]

On 9/2/19 4:40 PM, Seth Mattinen wrote:
> May the world come to an end if someone dares to have an independent 
> thought or shares original information that can't be backed up by at 
> least 50 crosschecked references.
Actually, independent thought or original information is welcome to
anyone with a brain, as long as the author shows his/her work such that
it can be verified and reproduced by others.  You don't need a ton of
references to the work (and conclusions) of others if you do a complete
job yourself.

There is a reason for the joke publication _The Journal of
Irreproducible Results_, started in 1955.  So many "scientific"
publications have this little tiny problem: no one can duplicate the work.

Re: Weekly Routing Table Report

[Masataka Ohta]

Seth Mattinen wrote:

May the world come to an end if someone dares to have an independent 
thought or shares original information that can't be backed up by at 
least 50 crosschecked references.


Unlike references to facts, references to thought are required when
the thought is not purely original and derived from someone else's
thought.

As such, if the thought is really independent, no references necessary.

Masataka Ohta

Re: Weekly Routing Table Report

[Seth Mattinen]

On 9/2/19 15:02, Masataka Ohta wrote:



then applying that very same standard of
evidence to your assertions leads directly to "can safely be ignored"


As I already wrote:

 > The following page by Geoff Huston is better than your delusion.
 > http://www.potaroo.net/ispcolumn/2001-03-bgp.html
 > What is driving this recent change to exponential growth
 > of the routing table?
 > In a word, multi-homing.

feel free to verify it.



May the world come to an end if someone dares to have an independent 
thought or shares original information that can't be backed up by at 
least 50 crosschecked references.

Re: Weekly Routing Table Report

[Masataka Ohta]

Valdis Klētnieks wrote:


If you think we should blindly believe your unfounded statement
not supported by any verifiable reference, that is the
condescending behavior.


As you can see, that you finally mentioned rfc1518 as reference
helped a lot to suppress unfounded and, thus, useless messages
from you, because I verified the rfc to find that all of your
points are denied.

That's the point to have verifiable references.


Well Masataka... If "Owen DeLong, who was widely known to have been in an
actual job position to know of certain facts, stating these facts" isn't
sufficient evidence for you,


I can't see any confirmed facts. Moreover, even if some of his point
on a single company might be valid, it is nothing for the discussion on
the entire Internet.


then applying that very same standard of
evidence to your assertions leads directly to "can safely be ignored"


As I already wrote:

> The following page by Geoff Huston is better than your delusion.
> http://www.potaroo.net/ispcolumn/2001-03-bgp.html
> What is driving this recent change to exponential growth
> of the routing table?
> In a word, multi-homing.

feel free to verify it.

Masataka Ohta

Re: Weekly Routing Table Report

[Nick Morrison]

> On 2. Sep 2019, at 15:49, Valdis Klētnieks  wrote:
> 
> *plonk* (the sound of an email address dropping into a not-often-used ignore 
> file)

mmhmm nice nerd burn. ouchie.

Re: Weekly Routing Table Report

[Valdis Klētnieks]

On Mon, 02 Sep 2019 14:02:43 +0900, Masataka Ohta said:
> If you think we should blindly believe your unfounded statement
> not supported by any verifiable reference, that is the
> condescending behavior.

Well Masataka... If "Owen DeLong, who was widely known to have been in an
actual job position to know of certain facts, stating these facts" isn't
sufficient evidence for you, then applying that very same standard of
evidence to your assertions leads directly to "can safely be ignored"

*plonk* (the sound of an email address dropping into a not-often-used
ignore file)


pgpA1j3jgYBYh.pgp
Description: PGP signature

Re: Weekly Routing Table Report

[Jared Mauch]

> On Sep 2, 2019, at 9:33 AM, Tony Finch  wrote:
> 
> Patrick W. Gilmore  wrote:
>> 
>> This time I waited for 768,000. (Everyone happy now?)
> 
> I thought the magic number for breaking old Cisco gear was 786432
> (768 * 1024) ... there was a panic about it earlier this year but growth
> slowed so it didn't happen as soon as they feared.
> 
> https://www.zdnet.com/article/some-internet-outages-predicted-for-the-coming-month-as-768k-day-approaches/
> 
> But looking at https://twitter.com/bgp4_table I see we passed the higher
> thresold (by some metrics) last month without any apparent routing
> failures so maybe the old Cisco gear isn't very important any more!

It may be that there were failures but not at the core, which is more likely.  
I recall writing the internal technical note on the edge devices when we hit 
128k and 256k numbers, especially as I was a promoter of u-RPF and this halved 
the TCAM size.  It was only certain devices/customers that may have seen an 
issue, AND only for new routes not older stable ones.  People who want to 
promote BGP churn as a platform solution need to keep this in mind.  It also 
matters if you have the ability to disaggregate your FIB (default) vs RIB.  I’m 
seeing more of this right now which I think is overall good.  Don’t need to 
install all those routes in hardware if they’re all going the same way.

Re: Weekly Routing Table Report

[Tony Finch]

Patrick W. Gilmore  wrote:
>
> This time I waited for 768,000. (Everyone happy now?)

I thought the magic number for breaking old Cisco gear was 786432
(768 * 1024) ... there was a panic about it earlier this year but growth
slowed so it didn't happen as soon as they feared.

https://www.zdnet.com/article/some-internet-outages-predicted-for-the-coming-month-as-768k-day-approaches/

But looking at https://twitter.com/bgp4_table I see we passed the higher
thresold (by some metrics) last month without any apparent routing
failures so maybe the old Cisco gear isn't very important any more!

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
North Foreland to Selsey Bill: Southwesterly veering westerly, 4 or 5,
occasionally 6 at first in east. Smooth or slight, becoming slight,
occasionally moderate. Showers later. Good.

Re: Weekly Routing Table Report

[Masataka Ohta]

Scott Weeks wrote:


Yes, my apologies for no reference.  Further, I have no URL to
point to as I read the book. (actual book; no e-something)

Here's something:  http://pouzinsociety.org


as I can't find open access papers or something like that there,
let me stick to wikipedia.


Like the book, in the Wikipedia article you have to get through
or skip the first part.  In the book, that's the first 5 or so
chapters.  He just describes why, in his opinion, previous things
have failed and the way he does it turns a lot of folks off.


Another major misunderstanding of him is that he is not aware that
domain name with MX is application name and there are proposals
(though unnecessarily complicated) such as SRV to cover other
applications beyond SMTP. With SRV, non-default port numbers do not
have to be specified in URLs.

So, we already have application names of domain names and mapping
mechanism between names and addresses/port_numers of DNS.

E2E (end-to-end principle) is not relevant


That someone can not recognize relevance between something and the
E2E principle does not mean much.

IPv6 is/was a waste of time


True, but, the reason is because IPv4 Internet with DNS, TCP
and NAT is good enough.

That TCP identifies connections only by single source and destination
addresses is certainly a problem. But, the least painful solution
is to extend TCP to be able to identify connections by multiple
addresses.

Properly designed NAT can save IP addresses a lot still keeping the
E2E transparency.


The RINA's fundamental principles are that computer
networking is just Inter-Process Communication or IPC,


That is a too much computer centric view not very
applicable to communications involving human beings,
where the E2E argument must often be applied to human
beings (true end) behind applications (tentative end
in a computer).

Masataka Ohta

Re: Weekly Routing Table Report

[Ross Tajvar]

Is anyone else getting flashbacks to the guy who said he solved the spam
problem?

I don't think this conversation is going anywhere productive.

On Mon, Sep 2, 2019 at 1:05 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Owen DeLong wrote:
>
> > My knowledge in this case is having been an HE employee for several
> > years. Admittedly, that was some time ago, but I am pretty sure I would
> > have heard of any major acquisitions by HE.
>
> If you think we should blindly believe your unfounded statement
> not supported by any verifiable reference, that is the
> condescending behavior.
>
>  > You offer no counter-argument nor any reason that my knowledge is
>  > inaccurate,
>
> I'm saying your opinion is untrustworthy.
>
> Masataka Ohta
>

Re: Weekly Routing Table Report

[Masataka Ohta]

Owen DeLong wrote:


My knowledge in this case is having been an HE employee for several
years. Admittedly, that was some time ago, but I am pretty sure I would
have heard of any major acquisitions by HE.


If you think we should blindly believe your unfounded statement
not supported by any verifiable reference, that is the
condescending behavior.

> You offer no counter-argument nor any reason that my knowledge is
> inaccurate,

I'm saying your opinion is untrustworthy.

Masataka Ohta

Re: Weekly Routing Table Report

[Scott Weeks]

--- mo...@necom830.hpcl.titech.ac.jp wrote:
From: Masataka Ohta 
Scott Weeks wrote:

> I have been reading your posts on IETF and here regarding the
> above and I'm curious as to your thoughts on John Day's RINA.

As you give no reference, let's rely on wikipedia

https://en.wikipedia.org/wiki/Recursive_Internetwork_Architecture



Yes, my apologies for no reference.  Further, I have no URL to
point to as I read the book. (actual book; no e-something)

Here's something:  http://pouzinsociety.org

Like the book, in the Wikipedia article you have to get through 
or skip the first part.  In the book, that's the first 5 or so 
chapters.  He just describes why, in his opinion, previous things 
have failed and the way he does it turns a lot of folks off.  
Likewise, I skipped the last 1-2 chapters.  So in the Wikipedia 
article skip to the Introduction" section.


A couple more things:

---
E2E (end-to-end principle) is not relevant

IPv6 is/was a waste of time

The RINA's fundamental principles are that computer 
networking is just Inter-Process Communication or IPC,
and that layering should be done based on scope/scale, 
with a single recurring set of protocols, rather than 
function, with specialized protocols.
---



 more from Wikipedia 

The IPC model of RINA concretizes distributed applications in 
Distributed Application Facilities or DAFs, as illustrated in 
Figure 2. A DAF is composed of two or more Distributed Application 
or DAPs, which collaborate to perform a task. These DAPs 
communicate using a single application protocol called Common 
Distributed Application Protocol or CDAP, which enables two DAPs 
to exchange structured data in the form of objects. All of the 
DAP's externally visible information is represented by objects and 
structured in a Resource Information Base or RIB, which provides a 
naming schema and a logical organization to the objects known by 
the DAP (for example a naming tree). CDAP allows the DAPs to 
perform six remote operations on the peer's objects: create, delete, 
read, write, start and stop.

In order to exchange information, DAPs need an underlying facility 
that provides communication services to them. This facility is 
another DAF whose task is to provide and manage Inter Process 
Communication services over a certain scope, and is called a 
Distributed IPC Facility or DIF. A DIF can be thought of as a layer, 
and enables a DAP to allocate flows to one or more DAPs, by just 
providing the names of the targeted DAPs and the characteristics 
required for the flow such as bounds on data loss and delay, 
in-order delivery of data, reliability, etc. 

DIFs, being DAFs, can in turn use other underlying DIFs themselves. 
This is the recursion of the RINA.


scott














and restrict scope only for multihoming.

Then, it is true that:

 > 1972. Multi-homing not supported by the ARPANET.

which means current specifications do not support multihoming very well.

but, the statement

 > The solution was obvious: as in operating systems, a logical address
 > space naming the nodes (hosts and routers) was required on top of the
 > physical interface address space.

is wrong, because it is enough to let transport layer identify
connections based on a set of physical interface addresses of
all the interfaces, which is what draft-ohta-e2e-multihoming-*
proposes.

That is, he misunderstand restrictions by the current specification
something inevitably required by layering.

 > It tosses all this on its head.

If you have some text of RINA denying the E2E argument, quote it
with URLs please.

Masataka Ohta

Re: Weekly Routing Table Report

[Owen DeLong]

> On Aug 31, 2019, at 18:48 , Masataka Ohta  
> wrote:
> 
> Owen DeLong wrote:
> 
 However, since you don’t like Comcast, let’s try another one that
 has few (if any) mergers involved:
>>> I don't think so.
>> Care to expand on this?
> 
> See below.
> 
>> No... HE has not acquired a significant number of other businesses to
>> the best of my knowledge.
> 
> People, including me, are not interested in relying on your
> knowledge.

My knowledge in this case is having been an HE employee for several
years. Admittedly, that was some time ago, but I am pretty sure I would
have heard of any major acquisitions by HE.
> 
> If you think we should blindly believe your unfounded statement
> not supported by any verifiable reference, that is the
> condescending behavior.

Do you have contravening knowledge or information? HE Is a private company,
so it’s nearly impossible to get detailed information about such things.

You offer no counter-argument nor any reason that my knowledge is inaccurate,
you simply claim it’s not credible because you don’t like what it says. That’s
far more condescending.

> Moreover, your logic is flawed, because, even though HE may acquire
> only one business, the acquired business may have acquired a lot of
> other businesses.

The business I know it acquired was (at the time of acquisition) a relatively
small east coast ISP startup. It did not have a significant history of 
acquisitions.

>> Repeating your condescending statement doesn't make it any more
>> accurate the second time.
> 
> That is an accurate and proper reaction to those who insists that
> Moore's law were not ending.

We can again agree to disagree. You’ve offered no proof, no actual evidence
to support this, only your own assertion. To quote your own statement:

“If you think we should blindly believe your unfounded statement not supported
by any verifiable reference…”

Owen

Re: Weekly Routing Table Report

[Masataka Ohta]

Valdis Kletnieks wrote:


Read the first three paragraphs of abstract of the draft:


And it doesn't actually explain why it's better.


multihoming is supported by transport (TCP) or application
layer (UDP etc.) of end systems and does not introduce any
problem in the network does not introduce any problem in
the network

is the reason.


The Architecture of End to End Multihoming

However, the draft is lacking in any description of an actual architecture.


That is a very convincing argument made by a person who haven't read
title or abstract of the draft at all.

Thank you very much.

> Read RFC1518, which *does* describe an architecture, and ask yourself
> what's in that RFC that isn't in your draft.

*YOU* should read rfc1518. Then, you could have noticed that the rfc,
despite its title, says:

   Status of this Memo

   This RFC specifies an Internet standards track protocol for the
   Internet community

though, with modern terminology, the rfc is rather a BCP than
on standard track.

Masataka Ohta

Re: Weekly Routing Table Report

[Masataka Ohta]

Owen DeLong wrote:


However, since you don’t like Comcast, let’s try another one that
has few (if any) mergers involved:


I don't think so.


Care to expand on this?


See below.


No... HE has not acquired a significant number of other businesses to
the best of my knowledge.


People, including me, are not interested in relying on your
knowledge.

If you think we should blindly believe your unfounded statement
not supported by any verifiable reference, that is the
condescending behavior.

Moreover, your logic is flawed, because, even though HE may acquire
only one business, the acquired business may have acquired a lot of
other businesses.


Repeating your condescending statement doesn't make it any more
accurate the second time.


That is an accurate and proper reaction to those who insists that
Moore's law were not ending.

Masataka Ohta

Re: Weekly Routing Table Report

[Valdis Klētnieks]

On Sun, 01 Sep 2019 09:04:03 +0900, Masataka Ohta said:

> > All I see there is some handwaving about separating something from
> > something else, without even a description of why it was better than
> > what was available when you wrote the draft.
>
> Read the first three paragraphs of abstract of the draft:

And it doesn't actually explain why it's better. It says it's different, but
doesn't give reasons to do it other than "it's different".

> Read the title of the draft. The draft is not intended to describe
> protocol details.

In other words, you have a wish list, not a workable idea.

> > Try attaching an actual protocol specification
>
> Read the title of the draft.

The Architecture of End to End Multihoming

However, the draft is lacking in any description of an actual architecture.

Read RFC1518, which *does* describe an architecture, and ask yourself
what's in that RFC that isn't in your draft.


pgp3DEuIMI5Qp.pgp
Description: PGP signature

Re: Weekly Routing Table Report

[Owen DeLong]

> On Aug 31, 2019, at 05:04, Masataka Ohta  
> wrote:
> 
> Owen DeLong wrote:
> 
>> However, since you don’t like Comcast, let’s try another one that has
>> few (if any) mergers involved:
> 
> I don't think so.

Care to expand on this?
> 
>> AS6939 — 125 prefixes...
> 
> Are you spamming?

No... HE has not acquired a significant number of other businesses to the best 
of my knowledge. 

> 
>> Admittedly some of this appears to be TE routes, but compare with:
>> 2001::/32 2001:470::/32 2001:470:1A::/48 2001:DF2:7900::/48
> 
> If you are saying some merger happened before v6 transition,
> which explains why there are less v6 prefix than v4, I can agree
> with you.
> 
> But, so what?

To the best of my knowledge, HE transitioned to v6 very early in their history, 
so I tend to doubt it. 

> 
>>> Without automatic renumbering, IPv6 is of no help against mergers.
>> Merging 10 organizations each of whom have 27 IPv6 prefixes = 270
>> prefixes. Merging 10 organizations each of whom have 125 IPv4
>> prefixes = 1250 prefixes.
> 
> The number of prefixes by swamp is recognized to be not a problem
> even when we were discussing it in 1998 when there was only less
> than 5 prefixes.
> 
 Sure, but the number of multi homed sites is way _WAY_ less than
 the IPv4 routing table size.
> 
>> Yeah, not quite the whole story in that one word… Let's look at what
>> is driving that increase in "multihoming"…
> 
> OK. You admit that the problem is caused by multihoming. OK.

No, I admit multihoming is one of several factors. 

> 
>>> I don't think I must explain the current routing practice here.
>> You don’t need to explain the current routing practice, but if you
>> want to be taken seriously, simply assuming that every possible /24
>> in IPv4 and/or every possible /48 in IPv6 will be eventually
>> advertised is a case of reductio ad absurdum. I was trying to give
>> you a chance to provide a better argument for your position.
> 
> I don't think I need such chance as my argument is already good enough.

We can agree to disagree about this as is usually the case. 

> 
>> While I appreciate that you enjoy speaking to people in condescending
>> tones, looking at the history and current trends shows that we are in
>> a period where Moore's law is leveling off.
> 
> I'm afraid you are not very familiar with semiconductor technology
> trend.

Repeating your condescending statement doesn’t make it any more accurate the 
second time. 

Owen

Re: Weekly Routing Table Report

[Masataka Ohta]

On 2019/09/01 9:21, Ross Tajvar wrote:

There are other articles, some of which are peer reviewed papers,
describing details.


Can you link those?


For detailed example of modified TCP:

https://tools.ietf.org/html/draft-arifumi-tcp-mh-00

For automatic renumbering:

https://dl.acm.org/citation.cfm?id=2089037

Masataka Ohta

Re: Weekly Routing Table Report

[Ross Tajvar]

> There are other articles, some of which are peer reviewed papers,
> describing details.

Can you link those?

Re: Weekly Routing Table Report

[Masataka Ohta]

Valdis Klētnieks wrote:


The solution is:

https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03


All I see there is some handwaving about separating something from
something else, without even a description of why it was better than
what was available when you wrote the draft.


Read the first three paragraphs of abstract of the draft:

   This memo describes the architecture of end to end multihoming.  End
   to end multihoming does not burden routing system for multihoming.
   That is, even extensive use of end to end multihoming does not
   increase the number of entries in a global routing table.

   Traditionally with IPv4, multihoming capability is offered by an
   intelligent routing system, which, as is always the case with
   violating the end to end principle, lacks scalability on a global
   routing table size and robustness against link failures.

   On the other hand, with end to end multihoming, multihoming is
   supported by transport (TCP) or application layer (UDP etc.) of end
   systems and does not introduce any problem in the network and works
   as long as there is some connectivity between the end systems.


I don't see anything about how it's supposed to work - for example, if my cell
phone had an IP address via DHCP from my home wireless router but also has an
IPv6 from cellular connection, how *exactly* does it *securely* fall back to
cellular if a thunderstorn knocks out Comcast's gear in the area?


Read the title of the draft. The draft is not intended to describe
protocol details.

There are other articles, some of which are peer reviewed papers, 
describing details.


But, first thing for you to do is to read the title and the abstract
section of the architectural draft


Try attaching an actual protocol specification


Read the title of the draft.

Masataka Ohta

Re: Weekly Routing Table Report

[Valdis Klētnieks]

On Sat, 31 Aug 2019 12:04:43 +0900, Masataka Ohta said:

> The solution is:
>
>   https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03

All I see there is some handwaving about separating something from
something else, without even a description of why it was better than
what was available when you wrote the draft.

I don't see anything about how it's supposed to work - for example, if my cell
phone had an IP address via DHCP from my home wireless router but also has an
IPv6 from cellular connection, how *exactly* does it *securely* fall back to
cellular if a thunderstorn knocks out Comcast's gear in the area?

It's little details like that which were why your IETF draft wasn't taken
seriously, and your commentary today isn't doing any better.

Try attaching an actual protocol specification - preferably one that you've
actually got at least somewhat-working software to implement it. I guarantee
that  you'll learn a few things in the process...


pgpjcBVqgRFRN.pgp
Description: PGP signature

Re: Weekly Routing Table Report

[Masataka Ohta]

Scott Weeks wrote:


I have been reading your posts on IETF and here regarding the
above and I'm curious as to your thoughts on John Day's RINA.


As you give no reference, let's rely on wikipedia

https://en.wikipedia.org/wiki/Recursive_Internetwork_Architecture

and restrict scope only for multihoming.

Then, it is true that:

> 1972. Multi-homing not supported by the ARPANET.

which means current specifications do not support multihoming very well.

but, the statement

> The solution was obvious: as in operating systems, a logical address
> space naming the nodes (hosts and routers) was required on top of the
> physical interface address space.

is wrong, because it is enough to let transport layer identify
connections based on a set of physical interface addresses of
all the interfaces, which is what draft-ohta-e2e-multihoming-*
proposes.

That is, he misunderstand restrictions by the current specification
something inevitably required by layering.

> It tosses all this on its head.

If you have some text of RINA denying the E2E argument, quote it
with URLs please.

Masataka Ohta

Re: Weekly Routing Table Report

[Scott Weeks]

From: Masataka Ohta 

If you can't accept the following principle of the End to End
argument:

The function in question can completely and correctly be
implemented only with the knowledge and help of the
application standing at the end points of the
communication system.
---


I have been reading your posts on IETF and here regarding the 
above and I'm curious as to your thoughts on John Day's RINA.  
It tosses all this on its head.

scott

Re: Weekly Routing Table Report

[Ross Tajvar]

> I don't think I need such chance as my argument is already good enough.

I'm curious if you're able to convince anyone that your thoughts are valid
and correct with such an attitude.

Re: Weekly Routing Table Report

[Masataka Ohta]

Owen DeLong wrote:


However, since you don’t like Comcast, let’s try another one that has
few (if any) mergers involved:


I don't think so.


AS6939 — 125 prefixes...


Are you spamming?


Admittedly some of this appears to be TE routes, but compare with:

2001::/32 2001:470::/32 2001:470:1A::/48 2001:DF2:7900::/48


If you are saying some merger happened before v6 transition,
which explains why there are less v6 prefix than v4, I can agree
with you.

But, so what?


Without automatic renumbering, IPv6 is of no help against mergers.


Merging 10 organizations each of whom have 27 IPv6 prefixes = 270
prefixes. Merging 10 organizations each of whom have 125 IPv4
prefixes = 1250 prefixes.


The number of prefixes by swamp is recognized to be not a problem
even when we were discussing it in 1998 when there was only less
than 5 prefixes.


Sure, but the number of multi homed sites is way _WAY_ less than
the IPv4 routing table size.



Yeah, not quite the whole story in that one word… Let's look at what
is driving that increase in "multihoming"…


OK. You admit that the problem is caused by multihoming. OK.


I don't think I must explain the current routing practice here.


You don’t need to explain the current routing practice, but if you
want to be taken seriously, simply assuming that every possible /24
in IPv4 and/or every possible /48 in IPv6 will be eventually
advertised is a case of reductio ad absurdum. I was trying to give
you a chance to provide a better argument for your position.


I don't think I need such chance as my argument is already good enough.


While I appreciate that you enjoy speaking to people in condescending
tones, looking at the history and current trends shows that we are in
a period where Moore's law is leveling off.


I'm afraid you are not very familiar with semiconductor technology
trend.

Masataka Ohta

Re: Weekly Routing Table Report

[Masataka Ohta]

Nick Hilliard wrote:


Your proposal is almost a text-book case of RFC1925, section 6:


FYI, the rfc was published on 1 April.


I'm aware of the date that rfc1925 was published and the significance
of the date, and also that rfc1925 was intended to take a humorous
approach towards some very fundamental, recurrent themes which
continue to present themselves in networking theory and practice.


Thank you for your rhetoric.

Masataka Ohta

Re: Weekly Routing Table Report

[Nick Hilliard]

Masataka Ohta wrote on 31/08/2019 12:14:

Your proposal is almost a text-book case of RFC1925, section 6:


FYI, the rfc was published on 1 April.


I'm aware of the date that rfc1925 was published and the significance of 
the date, and also that rfc1925 was intended to take a humorous approach 
towards some very fundamental, recurrent themes which continue to 
present themselves in networking theory and practice.


No-one is compelled to pay attention to anything rfc1925 for this 
reason, but anyone dismissing it will do so to their own disadvantage.


I.e. instead of having network level complexity, you're proposing to 
shift the problem to maintaining both state and network into the host 
level. No doubt it has some benefits, but this comes at the cost of 
bringing dfz complexity down to the host and all the consequent 
support, scaling and management headaches associated with that. I.e. 
the problem space shifts, but is not solved.


So, you are joking, aren't you?


We need agree to disagree then.  I wish you well.

Nick

Re: Weekly Routing Table Report

[Owen DeLong]

> On Aug 31, 2019, at 02:51 , Masataka Ohta  
> wrote:
> 
> Owen DeLong wrote:
> 
>> Consider, for example AS7922
> 
> COMCAST is not a good example.

It seemed as good as any… Also, note that many of the Comcast mergers ended up 
in other
Comcast ASNs, possibly not changing ASNs either?

However, since you don’t like Comcast, let’s try another one that has few (if 
any) mergers involved:

AS6939 — 125 prefixes...

5.152.177.0/24
5.152.179.0/24
5.152.181.0/24
5.152.182.0/24
5.152.183.0/24
12.177.5.0/24
12.192.16.0/24
12.192.17.0/24
23.142.192.0/24
23.164.160.0/24
23.175.160.0/24
27.50.32.0/21
38.72.144.0/20
38.87.144.0/23
45.33.128.0/22
45.33.132.0/22
45.33.136.0/22
45.33.140.0/24
45.33.140.0/22
45.40.118.0/23
52.129.12.0/23
64.62.128.0/18
64.62.128.0/17
64.71.128.0/18
64.209.56.0/21
64.209.68.0/22
64.214.184.0/21
65.19.128.0/18
65.49.0.0/17
65.49.2.0/24
65.49.14.0/24
65.49.68.0/24
65.49.108.0/22
66.97.177.0/24
66.119.119.0/24
66.160.128.0/18
66.160.192.0/20
66.178.176.0/20
66.207.160.0/20
66.220.0.0/19
67.43.48.0/20
72.14.64.0/24
72.14.65.0/24
72.14.66.0/24
72.14.67.0/24
72.14.89.0/24
72.52.64.0/18
72.52.71.0/24
72.52.92.0/24
74.82.0.0/18
74.82.22.0/23
74.82.46.0/24
74.82.48.0/22
74.116.112.0/22
74.121.104.0/22
74.122.152.0/21
103.6.216.0/22
103.96.214.0/24
103.100.138.0/24
103.193.186.0/23
104.36.120.0/22
104.194.216.0/23
104.247.128.0/22
104.247.132.0/23
104.254.152.0/21
104.255.240.0/21
107.178.32.0/24
107.178.33.0/24
107.178.34.0/23
107.178.36.0/22
107.178.40.0/21
124.252.248.0/21
139.56.8.0/24
139.60.15.0/24
141.193.188.0/23
148.51.0.0/17
161.129.140.0/22
162.213.130.0/24
162.247.12.0/22
162.247.75.0/24
162.249.152.0/23
162.249.154.0/23
167.136.239.0/24
168.245.149.0/24
170.199.208.0/23
173.242.48.0/20
184.75.240.0/21
184.104.0.0/17
184.104.0.0/15
184.104.200.0/21
184.104.208.0/20
184.105.7.0/24
184.105.16.0/20
184.105.32.0/20
184.105.48.0/20
184.105.62.0/24
184.105.88.0/21
184.105.100.0/22
184.105.248.0/21
185.101.97.0/24
185.101.98.0/24
185.114.36.0/24
185.149.69.0/24
185.242.47.0/24
199.164.248.0/23
199.192.144.0/22
204.13.226.0/23
207.126.64.0/19
208.64.56.0/21
208.75.96.0/21
208.79.140.0/22
209.51.160.0/19
209.130.152.0/22
209.135.0.0/19
209.150.160.0/19
216.66.0.0/19
216.66.32.0/19
216.66.64.0/19
216.66.72.0/21
216.66.80.0/20
216.99.220.0/23
216.218.128.0/17
216.224.64.0/21
216.224.64.0/19
216.229.96.0/20

Admittedly some of this appears to be TE routes, but compare with:

2001::/32
2001:470::/32
2001:470:1A::/48
2001:DF2:7900::/48
2001:49E8::/32
2002::/16
2400:7A00::/32
2600:7000::/24
2602:FECA::/36
2602:FF06:725::/48
2604:A100:100::/48
2604:C800:::/48
2605:4C0::/32
2620:0:50C0::/48
2620:64:6000::/48
2620:138:C001::/48
2620:138:C002::/48
2A03:B2C0::/29
2A06:1C80::/32
2A09:2580::/29
2A09:2780::/29
2A09:3880::/29
2A09:3B80::/29
2A09:3D80::/29
2A09:E500::/29
2A09:F480::/29
2A09:FA80::/29

27 prefixes with most of them being obvious TE or customer carve-outs.

In fact, the first prefix appears to be a bogon from the IANA reserve, so I’m 
not sure why HE is originating a route for that.

If you still think this isn’t a good example, then pick a decent sized transit 
AS of your choosing and I’ll run their statistics.


> 
>> but, rather organic customer growth and RIR applications over time.
> 
> No, if you know theory and practice of how additional address ranges
> are allocated as a result of growth, you could have noticed that the
> large number of prefixes of COMCAST should mostly be a result of
> mergers, where merged parts won't renumber their hosts.
> 
>> That’s the kind of prefix growth we should be able to mostly avoid in
>> IPv6 that is rather rampant in IPv4.
> 
> Without automatic renumbering, IPv6 is of no help against mergers.

Merging 10 organizations each of whom have 27 IPv6 prefixes = 270 prefixes.
Merging 10 organizations each of whom have 125 IPv4 prefixes = 1250 prefixes.

IPv6 is of some help even in the case of mergers…


> 
>> Sure, but the number of multi homed sites is way _WAY_ less than the
>> IPv4 routing table size.
> 
> The following page by Geoff Huston is better than your delusion.
> 
>   http://www.potaroo.net/ispcolumn/2001-03-bgp.html
>   What is driving this recent change to exponential growth
>   of the routing table?
>   In a word, multi-homing.

Yeah, not quite the whole story in that one word… Let’s look at what is driving 
that increase
in “multihoming”…

While it’s true that cost reduction for circuits has made multihoming more 
practical, it’s also true
that IPv4 scarcity is driving a lot of this as ISPs are less and less willing 
to provide free addresses
to customers driving the economics for smaller and smaller customers to get 
tiny fractions of space
from the remaining limited pools at various RIRs (e.g. ARIN NRPM 4.10 set-aside 
for v6 transition,
APNIC last /8 policy, RIPE last /8 policy, etc.).

Once you’re getting to the point of BYOA with your ISP, it’s really not much of 
a farther step to get an
ASN to go with that and 

Re: Weekly Routing Table Report

[Masataka Ohta]

Nick Hilliard wrote:


If you can't accept the following principle of the End to End
argument:

 The function in question can completely and correctly be
 implemented only with the knowledge and help of the
 application standing at the end points of the
 communication system.


this is a straw man argument.


The text is in the original paper on the principle:

End-To-End Arguments in System Design
J. H. SALTZER, D. P. REED, and D. D. CLARK

http://groups.csail.mit.edu/ana/Publications/PubPDFs/End-to-End%20Arguments%20in%20System%20Design.pdf

E2E works regardless of the current 
network-based multihoming mechanism or the proposals in 
draft-ohta-e2e-multihoming.

As the next sentence of the paper is:

Therefore, providing that questioned function as a feature
of the communication system itself is not possible

which means:

Therefore, providing multihoming as a feature
of the communication system itself is not possible

you are wrong.


Your proposal is almost a text-book case of RFC1925, section 6:


FYI, the rfc was published on 1 April.

I.e. instead of having network level complexity, you're proposing to 
shift the problem to maintaining both state and network into the host 
level. No doubt it has some benefits, but this comes at the cost of 
bringing dfz complexity down to the host and all the consequent support, 
scaling and management headaches associated with that. I.e. the problem 
space shifts, but is not solved.


So, you are joking, aren't you?


 > feel free to keep using POTS not smart phones.

Thank you, I certainly will. Conversely, please feel free to use 
arguments instead of rhetoric.


Instead of rhetoric, I argue by quoting from papers, hopefully not
published on 1 April, validity of which is well recognized.

Masataka Ohta

Re: Weekly Routing Table Report

[Nick Hilliard]

Masataka Ohta wrote on 31/08/2019 11:35:

If you can't accept the following principle of the End to End
argument:

 The function in question can completely and correctly be
 implemented only with the knowledge and help of the
 application standing at the end points of the
 communication system.


this is a straw man argument. E2E works regardless of the current 
network-based multihoming mechanism or the proposals in 
draft-ohta-e2e-multihoming.



validity of which is demonstrated by the Internet, and insist
that something complete and correct is not a solution
but a workaround


Your proposal is almost a text-book case of RFC1925, section 6:


   (6)  It is easier to move a problem around (for example, by moving
the problem to a different part of the overall network
architecture) than it is to solve it.


I.e. instead of having network level complexity, you're proposing to 
shift the problem to maintaining both state and network into the host 
level. No doubt it has some benefits, but this comes at the cost of 
bringing dfz complexity down to the host and all the consequent support, 
scaling and management headaches associated with that. I.e. the problem 
space shifts, but is not solved.


> feel free to keep using POTS not smart phones.

Thank you, I certainly will. Conversely, please feel free to use 
arguments instead of rhetoric.


Nick

Re: Weekly Routing Table Report

[Masataka Ohta]

Nick Hilliard wrote:


The solution is:

https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03

but IETF is working on stupid things like LISP only to increase 
load to the global routing system.


nothing comes for free.  Pushing the complexity down to the host
level is not a "solution", just a workaround with its own set of
problems.


If you can't accept the following principle of the End to End
argument:

The function in question can completely and correctly be
implemented only with the knowledge and help of the
application standing at the end points of the
communication system.

validity of which is demonstrated by the Internet, and insist
that something complete and correct is not a solution
but a workaround, feel free to keep using POTS not smart phones.

Masataka Ohta

Re: Weekly Routing Table Report

[Valdis Klētnieks]

On Sat, 31 Aug 2019 18:51:16 +0900, Masataka Ohta said:
> Owen DeLong wrote:

> >> With the current routing practice, the number will increase to 14M
> >> with IPv4 and a lot more than that with IPv6.
> >
> > I$B!G(Bm curious as to why you think that the number is bounded at 14M fo
r
> > IPv4 and why you think there will be so many more multi homed sites
> > in IPv6?
>
> I don't think I must explain the current routing practice here.

Actually, maybe you *should* explain how it will grow to 14M IPv4 routes.

Are there 13 million /24s still out there to be allocated?  Where will these
routes come from?



pgp6anjW_odTK.pgp
Description: PGP signature

Re: Weekly Routing Table Report

[Nick Hilliard]

Masataka Ohta wrote on 31/08/2019 04:04:

The solution is:

https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03

but IETF is working on stupid things like LISP only to increase
load to the global routing system.


nothing comes for free.  Pushing the complexity down to the host level  
is not a "solution", just a workaround with its own set of problems.


Nick

Re: Weekly Routing Table Report

[Masataka Ohta]

Owen DeLong wrote:


Consider, for example AS7922


COMCAST is not a good example.


but, rather organic customer growth and RIR applications over time.


No, if you know theory and practice of how additional address ranges
are allocated as a result of growth, you could have noticed that the
large number of prefixes of COMCAST should mostly be a result of
mergers, where merged parts won't renumber their hosts.


That’s the kind of prefix growth we should be able to mostly avoid in
IPv6 that is rather rampant in IPv4.


Without automatic renumbering, IPv6 is of no help against mergers.


Sure, but the number of multi homed sites is way _WAY_ less than the
IPv4 routing table size.


The following page by Geoff Huston is better than your delusion.

http://www.potaroo.net/ispcolumn/2001-03-bgp.html
What is driving this recent change to exponential growth
of the routing table?
In a word, multi-homing.

With the current routing practice, the number will increase to 14M 
with IPv4 and a lot more than that with IPv6.


I’m curious as to why you think that the number is bounded at 14M for
IPv4 and why you think there will be so many more multi homed sites
in IPv6?


I don't think I must explain the current routing practice here.


The problem is serious especially because Moore's law is ending.


People have been claiming that Moore's law is at an end longer than
we have been pushing for IPv6 deployment.


I'm afraid you are not very familiar with semiconductor technology
trend.

Masataka Ohta

RE: Weekly Routing Table Report

[adamv0025]

> Sent: Saturday, August 31, 2019 3:50 AM
> To: Paul Ebersman 
> 
> On Fri, 30 Aug 2019 20:27:10 -0600, Paul Ebersman said:
> 
> > BGP when under 2k-ish and CLNP for sins in past lives...
> 
> CLNP? Now there's a name I've not heard in a long time...
> 
> (Go ahead, admit it, you read that in Alec Guiness's voice :)

Ha, since reminiscing, anybody remembers the good old SNA or god forbid SDLC
to mainframes and then rocking it over DLSW?
Oh or here's another one Token-Ring routing anybody? 

We came quite a long way from these to current EVPN and SR-TE...  

But still I can't shake the feeling that back in the days architects were
somewhat more ingenious coming up with these extraordinary designs to work
around resource or protocol limitations. 
Now it's just down to simple slap more cpu/ram/tcam at the problem and
you're done I feel. Nowadays boxes can easily take 5x the current 768 in
tcam and in control-plane -only sky is the limit, so for example there's no
need for any clever RR infrastructure designs anymore to hold all the routes
in your AS control-plane. 
   
adam

Re: Weekly Routing Table Report

[Owen DeLong]

> On Aug 30, 2019, at 20:04 , Masataka Ohta  
> wrote:
> 
> Patrick W. Gilmore wrote:
> 
>> The hope is the v6 DFZ will not grow nearly as fast because of far
>> less fragmentation.
> 
> As the problem is caused by multihomed sites (including ISPs), there
> is no such hope.

Part of the problem is caused by multi homed sites. Much more of the problem is 
actually
caused by organizations needing multiple prefixes acquired over time through 
IPv4 slow
start and other similar rationing mechanisms deployed to try and create a fair 
allocation
strategy in light of IPv4 scarcity.

Consider, for example AS7922 which originates the following 124 prefixes 
according to
route-views:

23.7.80.0/20
23.24.0.0/15
23.30.0.0/15
23.33.186.0/24
23.40.176.0/20
23.41.0.0/20
23.49.56.0/24
23.58.92.0/24
23.67.49.0/24
23.68.0.0/14
23.194.116.0/22
23.213.134.0/23
23.217.129.0/24
24.0.0.0/12
24.16.0.0/13
24.30.0.0/17
24.34.0.0/16
24.40.0.0/18
24.40.64.0/20
24.60.0.0/14
24.91.0.0/16
24.98.0.0/15
24.104.0.0/17
24.104.128.0/19
24.118.0.0/16
24.124.128.0/17
24.125.0.0/16
24.126.0.0/15
24.128.0.0/16
24.129.0.0/17
24.130.0.0/15
24.147.0.0/16
24.153.64.0/19
24.218.0.0/16
24.245.0.0/18
50.73.0.0/16
50.76.0.0/14
50.128.0.0/9
50.227.16.0/22
50.227.20.0/22
64.56.32.0/19
64.139.64.0/19
65.34.128.0/17
65.96.0.0/16
66.30.0.0/15
66.41.0.0/16
66.56.0.0/18
66.176.0.0/15
66.208.192.0/18
66.229.0.0/16
66.240.0.0/18
67.160.0.0/11
68.32.0.0/11
68.80.0.0/13
68.86.80.0/20
69.136.0.0/13
69.180.0.0/15
69.240.0.0/12
70.88.0.0/14
71.24.0.0/14
71.56.0.0/13
71.192.0.0/12
71.224.0.0/12
72.55.0.0/17
72.247.190.0/24
74.16.0.0/12
74.92.0.0/14
74.144.0.0/12
75.64.0.0/13
75.72.0.0/15
75.74.0.0/16
75.75.0.0/17
75.75.128.0/18
75.144.0.0/13
76.16.0.0/12
76.96.0.0/11
76.128.0.0/11
96.6.80.0/20
96.17.145.0/24
96.17.164.0/24
96.17.165.0/24
96.17.166.0/24
96.64.0.0/11
96.96.0.0/12
96.112.0.0/13
96.120.0.0/14
96.124.0.0/16
96.128.0.0/10
96.192.0.0/11
98.32.0.0/11
98.192.0.0/10
104.69.216.0/22
104.69.220.0/23
104.70.48.0/20
104.70.64.0/20
104.70.178.0/24
104.77.121.0/24
104.77.150.0/24
104.109.53.0/24
107.0.0.0/14
107.4.0.0/15
162.148.0.0/14
173.8.0.0/13
173.160.0.0/13
173.222.176.0/22
174.48.0.0/12
174.160.0.0/11
184.25.157.0/24
184.28.64.0/23
184.28.68.0/23
184.28.117.0/24
184.51.52.0/22
184.51.207.0/24
184.86.251.0/24
184.108.0.0/14
184.112.0.0/12
198.0.0.0/16
198.137.252.0/23
198.178.8.0/21
204.11.116.0/22
208.39.128.0/18
209.23.192.0/22
209.23.192.0/18
216.45.128.0/17


A quick scan didn’t reveal significant overlap or even a lot of adjacent 
prefixes. As such, I don’t think you can blame multihoming or TE for this, but, 
rather organic customer growth and RIR applications over time.

That’s the kind of prefix growth we should be able to mostly avoid in IPv6 that 
is rather rampant in IPv4.

> With the current way of multihoming to compute available routes to
> multihomed sites by global routing system, the load, including routing
> table size, to the global routing system increases at least linearly
> to the number of multihomed sites.

Sure, but the number of multi homed sites is way _WAY_ less than the IPv4 
routing table size.

> Some people was aware of the problem when the size was 50,000.

When the size was 50,000, that was the primary source of the problem. Today, 
long prefixes issued due to scarcity constitute a much larger fraction of the 
problem than multi homed sites originating single prefixes.

> With the current routing practice, the number will increase to 14M
> with IPv4 and a lot more than that with IPv6.

I’m curious as to why you think that the number is bounded at 14M for IPv4 and 
why you think there will be so many more multi homed sites in IPv6?

> The solution is:
> 
>   https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03
> 
> but IETF is working on stupid things like LISP only to increase
> load to the global routing system.

Not that you’d be prejudiced in favor of your own draft or anything.

>> Also, even today TCAM ain’t cheap. Let’s hope it those numbers are
>> not "nothing".
> 
> The problem is serious especially because Moore's law is ending.

People have been claiming that Moore’s law is at an end longer than we have 
been pushing for IPv6 deployment.

TCAM ain’t cheap, but it’s also not the only solution to the problem and 
solutions are getting cheaper (per prefix) over time. 

Owen

Re: Weekly Routing Table Report

[Masataka Ohta]

Patrick W. Gilmore wrote:


The hope is the v6 DFZ will not grow nearly as fast because of far
less fragmentation.


As the problem is caused by multihomed sites (including ISPs), there
is no such hope.

With the current way of multihoming to compute available routes to
multihomed sites by global routing system, the load, including routing
table size, to the global routing system increases at least linearly
to the number of multihomed sites.

Some people was aware of the problem when the size was 50,000.

With the current routing practice, the number will increase to 14M
with IPv4 and a lot more than that with IPv6.

The solution is:

https://tools.ietf.org/html/draft-ohta-e2e-multihoming-03

but IETF is working on stupid things like LISP only to increase
load to the global routing system.


Also, even today TCAM ain’t cheap. Let’s hope it those numbers are
not "nothing".


The problem is serious especially because Moore's law is ending.

Masataka Ohta

Re: Weekly Routing Table Report

[bzs]

On August 30, 2019 at 15:09 patr...@ianai.net (Patrick W. Gilmore) wrote:
 > 
 > Stop and think about that for a second. You had a part in literally changing 
 > the world.

Some of us had a part in literally creating TheWorld(.com) :-)

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: Weekly Routing Table Report

[Valdis Klētnieks]

On Fri, 30 Aug 2019 20:27:10 -0600, Paul Ebersman said:

> BGP when under 2k-ish and CLNP for sins in past lives...

CLNP? Now there's a name I've not heard in a long time...

(Go ahead, admit it, you read that in Alec Guiness's voice :)


pgp6ZxG8xNXvp.pgp
Description: PGP signature

Re: Weekly Routing Table Report

[Wayne Bouchard]

On Fri, Aug 30, 2019 at 07:15:17PM -0700, Scott Weeks wrote:
> 
> 
> --- w...@typo.org wrote:
> 
> "WTF, PEOPLE??? CAN'T ANYONE AGGREGATE ANYMORE???"
> ---
> 
> 
> Is that like the NANOG version of "get off my lawn"? :)
> 
> scott
> bgp since ~50k

Hah!

"The internet woulda been perfect, if not for those meddling kids!"

---
Wayne Bouchard
w...@typo.org
Network Dude
http://www.typo.org/~web/

Re: Weekly Routing Table Report

[Paul Ebersman]

web> "WTF, PEOPLE??? CAN'T ANYONE AGGREGATE ANYMORE???"

surfer> Is that like the NANOG version of "get off my lawn"? :)

Lawns? You had lawns? :)

BGP when under 2k-ish and CLNP for sins in past lives...

Re: Weekly Routing Table Report

[Scott Weeks]

--- w...@typo.org wrote:

"WTF, PEOPLE??? CAN'T ANYONE AGGREGATE ANYMORE???"
---


Is that like the NANOG version of "get off my lawn"? :)

scott
bgp since ~50k

Re: Weekly Routing Table Report

[Wayne Bouchard]

On Fri, Aug 30, 2019 at 03:09:24PM -0400, Patrick W. Gilmore wrote:
> A very long time ago, I commented on this report hitting 250,000 prefixes. It 
> was a Big F*#@$&! Deal at the time. A quarter million prefixes in the DFZ? 
> Wow???.
> 
> Then I did it again at 500,000. People commented that I should have waited 
> for 512,000 - especially since a popular piece of kit was expected to fall 
> over at 512K prefixes. But I said I liked round numbers.
> 
> This time I waited for 768,000. (Everyone happy now?)

No, actually!

I came on board when there were about 32,000 prefixes and we were
panicked about that. "CIDRize or die", I think Sean Doran said. I
remember well the memory and cam struggles to keep up with growth. Its
phenomenal, yes, but also, "WTF, PEOPLE??? CAN'T ANYONE AGGREGATE
ANYMORE???"

:)

-Wayne

---
Wayne Bouchard
w...@typo.org
Network Dude
http://www.typo.org/~web/

Re: Weekly Routing Table Report

[Philip Smith]

It doesn't bode well with deaggregation in IPv6 going down to the /48 in
places I see it happen. A large chunk of the /48s out there are from
/32s. If that carries on, we'll have to be more afraid then I remember
us being at 30k IPv4 prefixes, 100k IPv4 prefixes, etc. :-(

Actually when I started doing this back in early 1999, it was to
supplement with a regional view of what Tony Bates was producing in the
CIDR Report. Sloppy code on my part back then as we didn't have "too
many prefixes". Didn't think I'd be doing this still, and have had to
sort the code many times since too. :-)

philip
--

Patrick W. Gilmore wrote on 31/8/19 06:40 :
> The hope is the v6 DFZ will not grow nearly as fast because of far less
> fragmentation.
> 
> But who knows?
> 
> Also, even today TCAM ain’t cheap. Let’s hope it those numbers are not
> “nothing”.
> 
> -- 
> TTFN,
> patrick
> 
>> On Aug 30, 2019, at 4:33 PM, Romeo Czumbil
>> mailto:romeo.czum...@tierpoint.com>> wrote:
>>
>> These numbers are nothing. Wait till IPv6 really start taking off.
>>
>>
>> -Original Message-
>> From: NANOG mailto:nanog-boun...@nanog.org>>
>> On Behalf Of Patrick W. Gilmore
>> Sent: Friday, August 30, 2019 3:09 PM
>> To: North American Operators' Group > <mailto:nanog@nanog.org>>
>> Subject: Re: Weekly Routing Table Report
>>
>> A very long time ago, I commented on this report hitting 250,000
>> prefixes. It was a Big F*#@$&! Deal at the time. A quarter million
>> prefixes in the DFZ? Wow….
>>
>> Then I did it again at 500,000. People commented that I should have
>> waited for 512,000 - especially since a popular piece of kit was
>> expected to fall over at 512K prefixes. But I said I liked round numbers.
>>
>> This time I waited for 768,000. (Everyone happy now?)
>>
>> To say “the Internet grew more than anyone expected” is beyond cliché
>> these days, but that does not make it any less true. The Internet has
>> transformed from a curiosity into something my son[*] and a good
>> portion of his entire generation cannot conceive of living without. A
>> great many people on this list had a part in making all that happen.
>>
>> Stop and think about that for a second. You had a part in literally
>> changing the world.
>>
>> It is a 3-day weekend in the US. A good time to pause for a few
>> minutes and consider what all of us accomplished together. Pat
>> yourselves on the back, raise a glass or whatever your personal
>> traditions are, and bask in the glory of a job well done.
>>
>> --
>> TTFN,
>> patrick
>>
>> [*] The fact I can say “my son” is probably even more amazing. But
>> that is a different story.
>>
>>
>>> On Aug 30, 2019, at 2:04 PM, Routing Analysis Role Account
>>> mailto:csc...@apnic.net>> wrote:
>>>
>>> This is an automated weekly mailing describing the state of the 
>>> Internet Routing Table as seen from APNIC's router in Japan.
>>>
>>> The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG 
>>> TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.
>>>
>>> Daily listings are sent to bgp-st...@lists.apnic.net
>>> <mailto:bgp-st...@lists.apnic.net>
>>>
>>> For historical data, please
>>> see 
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY=
>>>  .
>>>
>>> If you have any comments please contact Philip Smith
>>> mailto:pfsi...@gmail.com>>.
>>>
>>> Routing Table Report   04:00 +10GMT Sat 31 Aug, 2019
>>>
>>> Report Website:
>>> 
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY=
>>>  
>>> Detailed Analysis:  
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n
>>> et_current_=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpk
>>> Dj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=
>>> 1SzKtCXB1OQXt_kKzDwHmtLE8a44hKEkYUtraUzC3gI=
>>>
>>> Analysis Summary
>>> 
>>>
>>> BGP routing table entries examined:  768323
>>>   Prefixes after maximum aggregation (per

Re: Weekly Routing Table Report

[Patrick W. Gilmore]

The hope is the v6 DFZ will not grow nearly as fast because of far less 
fragmentation.

But who knows?

Also, even today TCAM ain’t cheap. Let’s hope it those numbers are not 
“nothing”.

-- 
TTFN,
patrick

> On Aug 30, 2019, at 4:33 PM, Romeo Czumbil  <mailto:romeo.czum...@tierpoint.com>> wrote:
> 
> These numbers are nothing. Wait till IPv6 really start taking off.
> 
> 
> -Original Message-
> From: NANOG mailto:nanog-boun...@nanog.org>> On 
> Behalf Of Patrick W. Gilmore
> Sent: Friday, August 30, 2019 3:09 PM
> To: North American Operators' Group mailto:nanog@nanog.org>>
> Subject: Re: Weekly Routing Table Report
> 
> A very long time ago, I commented on this report hitting 250,000 prefixes. It 
> was a Big F*#@$&! Deal at the time. A quarter million prefixes in the DFZ? 
> Wow….
> 
> Then I did it again at 500,000. People commented that I should have waited 
> for 512,000 - especially since a popular piece of kit was expected to fall 
> over at 512K prefixes. But I said I liked round numbers.
> 
> This time I waited for 768,000. (Everyone happy now?)
> 
> To say “the Internet grew more than anyone expected” is beyond cliché these 
> days, but that does not make it any less true. The Internet has transformed 
> from a curiosity into something my son[*] and a good portion of his entire 
> generation cannot conceive of living without. A great many people on this 
> list had a part in making all that happen.
> 
> Stop and think about that for a second. You had a part in literally changing 
> the world.
> 
> It is a 3-day weekend in the US. A good time to pause for a few minutes and 
> consider what all of us accomplished together. Pat yourselves on the back, 
> raise a glass or whatever your personal traditions are, and bask in the glory 
> of a job well done.
> 
> --
> TTFN,
> patrick
> 
> [*] The fact I can say “my son” is probably even more amazing. But that is a 
> different story.
> 
> 
>> On Aug 30, 2019, at 2:04 PM, Routing Analysis Role Account > <mailto:csc...@apnic.net>> wrote:
>> 
>> This is an automated weekly mailing describing the state of the 
>> Internet Routing Table as seen from APNIC's router in Japan.
>> 
>> The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG 
>> TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.
>> 
>> Daily listings are sent to bgp-st...@lists.apnic.net 
>> <mailto:bgp-st...@lists.apnic.net>
>> 
>> For historical data, please see 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY=
>>  
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY=>
>>  .
>> 
>> If you have any comments please contact Philip Smith > <mailto:pfsi...@gmail.com>>.
>> 
>> Routing Table Report   04:00 +10GMT Sat 31 Aug, 2019
>> 
>> Report Website: 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY=
>>  
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY=>
>>  
>> Detailed Analysis:  
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n 
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n>
>> et_current_=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpk
>> Dj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=
>> 1SzKtCXB1OQXt_kKzDwHmtLE8a44hKEkYUtraUzC3gI=
>> 
>> Analysis Summary
>> 
>> 
>> BGP routing table entries examined:  768323
>>   Prefixes after maximum aggregation (per Origin AS):  295832
>>   Deaggregation factor:  2.60
>>   Unique aggregates announced (without unneeded subnets):  370810
>> Total ASes present in the Internet Routing Table: 65326
>>   Prefixes per ASN: 11.76
>> Origin-only ASes present in the Internet Routing Table:   

RE: Weekly Routing Table Report

[Romeo Czumbil]

These numbers are nothing. Wait till IPv6 really start taking off.


-Original Message-
From: NANOG  On Behalf Of Patrick W. Gilmore
Sent: Friday, August 30, 2019 3:09 PM
To: North American Operators' Group 
Subject: Re: Weekly Routing Table Report

A very long time ago, I commented on this report hitting 250,000 prefixes. It 
was a Big F*#@$&! Deal at the time. A quarter million prefixes in the DFZ? Wow….

Then I did it again at 500,000. People commented that I should have waited for 
512,000 - especially since a popular piece of kit was expected to fall over at 
512K prefixes. But I said I liked round numbers.

This time I waited for 768,000. (Everyone happy now?)

To say “the Internet grew more than anyone expected” is beyond cliché these 
days, but that does not make it any less true. The Internet has transformed 
from a curiosity into something my son[*] and a good portion of his entire 
generation cannot conceive of living without. A great many people on this list 
had a part in making all that happen.

Stop and think about that for a second. You had a part in literally changing 
the world.

It is a 3-day weekend in the US. A good time to pause for a few minutes and 
consider what all of us accomplished together. Pat yourselves on the back, 
raise a glass or whatever your personal traditions are, and bask in the glory 
of a job well done.

--
TTFN,
patrick

[*] The fact I can say “my son” is probably even more amazing. But that is a 
different story.


> On Aug 30, 2019, at 2:04 PM, Routing Analysis Role Account  
> wrote:
> 
> This is an automated weekly mailing describing the state of the 
> Internet Routing Table as seen from APNIC's router in Japan.
> 
> The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG 
> TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.
> 
> Daily listings are sent to bgp-st...@lists.apnic.net
> 
> For historical data, please see 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY=
>  .
> 
> If you have any comments please contact Philip Smith .
> 
> Routing Table Report   04:00 +10GMT Sat 31 Aug, 2019
> 
> Report Website: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.net=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpkDj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=RDK_n-hawo1IaJSf4Q6HI-XszJ3Y2nqjqJIcsPf3tcY=
>  
> Detailed Analysis:  
> https://urldefense.proofpoint.com/v2/url?u=http-3A__thyme.rand.apnic.n
> et_current_=DwIFaQ=QbKJOwLIrSFJ6b5qo-Piqw=7c7AjRoUVcwQLzf0TJlbpk
> Dj0XZUiEY9edXj7_CVNLE=maFjVIkqOPdUWLkdE4FI1RUVSfvn9V7rEBtxr4BhRDk=
> 1SzKtCXB1OQXt_kKzDwHmtLE8a44hKEkYUtraUzC3gI=
> 
> Analysis Summary
> 
> 
> BGP routing table entries examined:  768323
>Prefixes after maximum aggregation (per Origin AS):  295832
>Deaggregation factor:  2.60
>Unique aggregates announced (without unneeded subnets):  370810
> Total ASes present in the Internet Routing Table: 65326
>Prefixes per ASN: 11.76
> Origin-only ASes present in the Internet Routing Table:   56226
> Origin ASes announcing only one prefix:   24072
> Transit ASes present in the Internet Routing Table:9100
> Transit-only ASes present in the Internet Routing Table:269
> Average AS path length visible in the Internet Routing Table:   4.3
>Max AS path length visible:  45
>Max AS path prepend of ASN ( 27978)  31
> Prefixes from unregistered ASNs in the Routing Table:27
>Number of instances of unregistered ASNs:27
> Number of 32-bit ASNs allocated by the RIRs:  28444
> Number of 32-bit ASNs visible in the Routing Table:   23268
> Prefixes from 32-bit ASNs in the Routing Table:  105688
> Number of bogon 32-bit ASNs visible in the Routing Table:14
> Special use prefixes present in the Routing Table:0
> Prefixes being announced from unallocated address space:288
> Number of addresses announced to Internet:   2834690304
>Equivalent to 168 /8s, 245 /16s and 241 /24s
>Percentage of available address space announced:   76.6
>Percentage of allocated address space announced:   76.6
>Percentage of available address space allocated:  100.0
>  

Re: Weekly Routing Table Report

[Patrick W. Gilmore]

A very long time ago, I commented on this report hitting 250,000 prefixes. It 
was a Big F*#@$&! Deal at the time. A quarter million prefixes in the DFZ? Wow….

Then I did it again at 500,000. People commented that I should have waited for 
512,000 - especially since a popular piece of kit was expected to fall over at 
512K prefixes. But I said I liked round numbers.

This time I waited for 768,000. (Everyone happy now?)

To say “the Internet grew more than anyone expected” is beyond cliché these 
days, but that does not make it any less true. The Internet has transformed 
from a curiosity into something my son[*] and a good portion of his entire 
generation cannot conceive of living without. A great many people on this list 
had a part in making all that happen.

Stop and think about that for a second. You had a part in literally changing 
the world.

It is a 3-day weekend in the US. A good time to pause for a few minutes and 
consider what all of us accomplished together. Pat yourselves on the back, 
raise a glass or whatever your personal traditions are, and bask in the glory 
of a job well done.

-- 
TTFN,
patrick

[*] The fact I can say “my son” is probably even more amazing. But that is a 
different story.


> On Aug 30, 2019, at 2:04 PM, Routing Analysis Role Account  
> wrote:
> 
> This is an automated weekly mailing describing the state of the Internet
> Routing Table as seen from APNIC's router in Japan.
> 
> The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
> TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.
> 
> Daily listings are sent to bgp-st...@lists.apnic.net
> 
> For historical data, please see http://thyme.rand.apnic.net.
> 
> If you have any comments please contact Philip Smith .
> 
> Routing Table Report   04:00 +10GMT Sat 31 Aug, 2019
> 
> Report Website: http://thyme.rand.apnic.net
> Detailed Analysis:  http://thyme.rand.apnic.net/current/
> 
> Analysis Summary
> 
> 
> BGP routing table entries examined:  768323
>Prefixes after maximum aggregation (per Origin AS):  295832
>Deaggregation factor:  2.60
>Unique aggregates announced (without unneeded subnets):  370810
> Total ASes present in the Internet Routing Table: 65326
>Prefixes per ASN: 11.76
> Origin-only ASes present in the Internet Routing Table:   56226
> Origin ASes announcing only one prefix:   24072
> Transit ASes present in the Internet Routing Table:9100
> Transit-only ASes present in the Internet Routing Table:269
> Average AS path length visible in the Internet Routing Table:   4.3
>Max AS path length visible:  45
>Max AS path prepend of ASN ( 27978)  31
> Prefixes from unregistered ASNs in the Routing Table:27
>Number of instances of unregistered ASNs:27
> Number of 32-bit ASNs allocated by the RIRs:  28444
> Number of 32-bit ASNs visible in the Routing Table:   23268
> Prefixes from 32-bit ASNs in the Routing Table:  105688
> Number of bogon 32-bit ASNs visible in the Routing Table:14
> Special use prefixes present in the Routing Table:0
> Prefixes being announced from unallocated address space:288
> Number of addresses announced to Internet:   2834690304
>Equivalent to 168 /8s, 245 /16s and 241 /24s
>Percentage of available address space announced:   76.6
>Percentage of allocated address space announced:   76.6
>Percentage of available address space allocated:  100.0
>Percentage of address space in use by end-sites:   99.3
> Total number of prefixes smaller than registry allocations:  257215
> 
> APNIC Region Analysis Summary
> -
> 
> Prefixes being announced by APNIC Region ASes:   206838
>Total APNIC prefixes after maximum aggregation:   61926
>APNIC Deaggregation factor:3.34
> Prefixes being announced from the APNIC address blocks:  201585
>Unique aggregates announced from the APNIC address blocks:84621
> APNIC Region origin ASes present in the Internet Routing Table:   1
>APNIC Prefixes per ASN:   20.16
> APNIC Region origin ASes announcing only one prefix:   2776
> APNIC Region transit ASes present in the Internet Routing Table:   1483
> Average APNIC Region AS path length visible:4.4
>Max APNIC Region AS path length visible: 29
> Number of APNIC region 32-bit ASNs visible in the Routing Table:   5015
> Number of APNIC addresses 

Re: Weekly Routing Table Report

[Philip Smith]

Hello Brough,

Very well spotted!! :-)

I finally fixed a problem in my analysis programme which was miscounting
the extended range of 32-bit ASNs (those from 65536 and above). It
wasn't counting them at all in fact, something spotted by one of our
industry colleagues a couple of months back. So the jump is caused by that.

Misery for me now is I have to go back through a few years of daily
reports and figure out when I made the change to cause the breakage. And
rerun everything (sigh).

The other bonus of the fix is that I'm dealing with 32-bit ASNs properly
now - I'm catching the 65536 to 131071 range as bogons, and also
catching any origin ASNs from above 458752 as bogons too.

Thanks!

philip
--

Brough Turner wrote on 4/2/17 05:35 :
> On Fri, Feb 3, 2017 at 1:02 PM, Routing Analysis Role Account <
> csc...@apnic.net> wrote:
> 
>> Transit ASes present in the Internet Routing Table:7547
> 
> 
> Last week there were 6561.
> I've seen the number jump a few or a dozen in one week, but nearly 1000 in
> one week??
> What am I missing?
> 
> Thanks,
> Brough
> 
> Brough Turner
> netBlazr Inc. – Free your Broadband!
> Mobile:  617-285-0433 <(617)%20285-0433>   Skype:  brough
> netBlazr Inc.  | Google+
>  | Twitter
>  | LinkedIn
>  | Facebook
>  | Blog
>  | Personal website
> 
> 

Re: Weekly Routing Table Report

[Brough Turner]

On Fri, Feb 3, 2017 at 1:02 PM, Routing Analysis Role Account <
csc...@apnic.net> wrote:

> Transit ASes present in the Internet Routing Table:7547


Last week there were 6561.
I've seen the number jump a few or a dozen in one week, but nearly 1000 in
one week??
What am I missing?

Thanks,
Brough

Brough Turner
netBlazr Inc. – Free your Broadband!
Mobile:  617-285-0433 <(617)%20285-0433>   Skype:  brough
netBlazr Inc.  | Google+
 | Twitter
 | LinkedIn
 | Facebook
 | Blog
 | Personal website

Re: Weekly Routing Table Report

[Philip Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Hugo,

Hugo Slabbert wrote on 5/09/2015 01:20 :
> 
>> BGP routing table entries examined:
>> 30167
> ...
>> Percentage of available address space announced:
>> 7.0 Percentage of allocated address space announced:
>> 7.0
> 
> erm...y'all missing some prefixes on the collector for the report?

Yes. :-(

Seems like the dump from the collector happened just after a BGP reset
(or something). I'm checking that now, or whether something else has
broken.

Sorry!!

philip
- --
-BEGIN PGP SIGNATURE-

iD8DBQFV6vZUnFcIO/K8+cERAtmoAKDjjz1Fzl3PvO7DY3OeMSYAUHrpfgCgh9PH
ttXi696fTFOS+6MpAmJdgv0=
=HExi
-END PGP SIGNATURE-

Re: Weekly Routing Table Report

[Colin Johnston]

that might be solved in future with a dump to a storage area, diff of previous 
dump and flag problem if diff show significant difference

colin

Sent from my iPhone

> On 5 Sep 2015, at 15:04, Philip Smith  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi Hugo,
> 
> Hugo Slabbert wrote on 5/09/2015 01:20 :
>> 
>>> BGP routing table entries examined:
>>> 30167
>> ...
>>> Percentage of available address space announced:
>>> 7.0 Percentage of allocated address space announced:
>>> 7.0
>> 
>> erm...y'all missing some prefixes on the collector for the report?
> 
> Yes. :-(
> 
> Seems like the dump from the collector happened just after a BGP reset
> (or something). I'm checking that now, or whether something else has
> broken.
> 
> Sorry!!
> 
> philip
> - --
> -BEGIN PGP SIGNATURE-
> 
> iD8DBQFV6vZUnFcIO/K8+cERAtmoAKDjjz1Fzl3PvO7DY3OeMSYAUHrpfgCgh9PH
> ttXi696fTFOS+6MpAmJdgv0=
> =HExi
> -END PGP SIGNATURE-

Re: Weekly Routing Table Report

[Hugo Slabbert]

BGP routing table entries examined:   30167

...

   Percentage of available address space announced:7.0
   Percentage of allocated address space announced:7.0


erm...y'all missing some prefixes on the collector for the report?

--
Hugo


signature.asc
Description: Digital signature

32-bit ASN acceptance by ISPs in ARIN region (was: Re: Weekly Routing Table Report)

[John Curran]

On Sep 20, 2013, at 2:51 PM, Routing Analysis Role Account csc...@apnic.net 
wrote:

 Analysis Summary
 
 ...
 Number of 32-bit ASNs allocated by the RIRs:   5066
 Number of 32-bit ASNs visible in the Routing Table:3947
 ...
 ARIN Region Analysis Summary
 
 ...
 Number of ARIN region 32-bit ASNs visible in the Routing Table:  21

Folks - 
 
 If you work for a Internet service provider, please check your readiness
 to accept customers with 32-bit ASNs as soon as possible.  While we still  
 have some 16-bit ASNs in ARIN's regional pool, availability is limited and 
 we do not anticipate receiving additional 16-bit ASN blocks from IANA.

 Not being able to use 32-bit ASNs in your network and support systems will  
 inevitably lead to confusion for those customers who are assigned them.

Thanks!
/John

John Curran
President and CEO
ARIN

Re: Weekly Routing Table Report

[Lori Jakab]

On 8/24/2012 11:33 AM, Routing Analysis Role Account wrote:

[...]

 Analysis Summary
 

 BGP routing table entries examined:  264582

Isn't this supposed to be 400K? What happened this week?

-Lori

 Prefixes after maximum aggregation:   97761
 Deaggregation factor:  2.71
 Unique aggregates announced to Internet: 119633
 Total ASes present in the Internet Routing Table: 29036
 Prefixes per ASN:  9.11
 Origin-only ASes present in the Internet Routing Table:   22245
 Origin ASes announcing only one prefix:   11565
 Transit ASes present in the Internet Routing Table:4486
 Transit-only ASes present in the Internet Routing Table:492
 Average AS path length visible in the Internet Routing Table:   4.6
 Max AS path length visible:  32
 Max AS path prepend of ASN ( 48687)  24
 Prefixes from unregistered ASNs in the Routing Table:   435
 Unregistered ASNs in the Routing Table: 144
 Number of 32-bit ASNs allocated by the RIRs:   3169
 Number of 32-bit ASNs visible in the Routing Table:2305
 Prefixes from 32-bit ASNs in the Routing Table:6164
 Special use prefixes present in the Routing Table:0
 Prefixes being announced from unallocated address space: 74
 Number of addresses announced to Internet:   2132781732
 Equivalent to 127 /8s, 31 /16s and 170 /24s
 Percentage of available address space announced:   57.5
 Percentage of allocated address space announced:   57.6
 Percentage of available address space allocated:   99.9
 Percentage of address space in use by end-sites:   93.3
 Total number of prefixes smaller than registry allocations:  117536

 APNIC Region Analysis Summary
 -

 Prefixes being announced by APNIC Region ASes:59813
 Total APNIC prefixes after maximum aggregation:   15336
 APNIC Deaggregation factor:3.90
 Prefixes being announced from the APNIC address blocks:   60438
 Unique aggregates announced from the APNIC address blocks:22879
 APNIC Region origin ASes present in the Internet Routing Table:2883
 APNIC Prefixes per ASN:   20.96
 APNIC Region origin ASes announcing only one prefix:806
 APNIC Region transit ASes present in the Internet Routing Table:609
 Average APNIC Region AS path length visible:4.7
 Max APNIC Region AS path length visible: 26
 Number of APNIC region 32-bit ASNs visible in the Routing Table:242
 Number of APNIC addresses announced to Internet:  551407040
 Equivalent to 32 /8s, 221 /16s and 205 /24s
 Percentage of available APNIC address space announced: 64.4

 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
 (pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
58368-59391, 131072-133119
 APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
 49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
222/8, 223/8,

 ARIN Region Analysis Summary
 

 Prefixes being announced by ARIN Region ASes: 96228
 Total ARIN prefixes after maximum aggregation:43322
 ARIN Deaggregation factor: 2.22
 Prefixes being announced from the ARIN address blocks:97518
 Unique aggregates announced from the ARIN address blocks: 38278
 ARIN Region origin ASes present in the Internet Routing Table:10585
 ARIN Prefixes per ASN: 9.21
 ARIN Region origin ASes announcing only one prefix:4892
 ARIN Region transit ASes present in the Internet Routing Table:1244
 Average ARIN Region AS path length visible: 4.0
 Max ARIN Region AS path length visible:  24
 Number of ARIN region 32-bit ASNs visible in the Routing Table:   7
 Number of ARIN addresses announced to Internet: 

Re: Weekly Routing Table Report

[joel jaeggli]

On 8/24/12 3:07 PM, Lori Jakab wrote:

On 8/24/2012 11:33 AM, Routing Analysis Role Account wrote:

[...]


Analysis Summary


BGP routing table entries examined:  264582

Isn't this supposed to be 400K? What happened this week?

yes it disagrees with the cidr report.

424791



-Lori


 Prefixes after maximum aggregation:   97761
 Deaggregation factor:  2.71
 Unique aggregates announced to Internet: 119633
Total ASes present in the Internet Routing Table: 29036
 Prefixes per ASN:  9.11
Origin-only ASes present in the Internet Routing Table:   22245
Origin ASes announcing only one prefix:   11565
Transit ASes present in the Internet Routing Table:4486
Transit-only ASes present in the Internet Routing Table:492
Average AS path length visible in the Internet Routing Table:   4.6
 Max AS path length visible:  32
 Max AS path prepend of ASN ( 48687)  24
Prefixes from unregistered ASNs in the Routing Table:   435
 Unregistered ASNs in the Routing Table: 144
Number of 32-bit ASNs allocated by the RIRs:   3169
Number of 32-bit ASNs visible in the Routing Table:2305
Prefixes from 32-bit ASNs in the Routing Table:6164
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space: 74
Number of addresses announced to Internet:   2132781732
 Equivalent to 127 /8s, 31 /16s and 170 /24s
 Percentage of available address space announced:   57.5
 Percentage of allocated address space announced:   57.6
 Percentage of available address space allocated:   99.9
 Percentage of address space in use by end-sites:   93.3
Total number of prefixes smaller than registry allocations:  117536

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:59813
 Total APNIC prefixes after maximum aggregation:   15336
 APNIC Deaggregation factor:3.90
Prefixes being announced from the APNIC address blocks:   60438
 Unique aggregates announced from the APNIC address blocks:22879
APNIC Region origin ASes present in the Internet Routing Table:2883
 APNIC Prefixes per ASN:   20.96
APNIC Region origin ASes announcing only one prefix:806
APNIC Region transit ASes present in the Internet Routing Table:609
Average APNIC Region AS path length visible:4.7
 Max APNIC Region AS path length visible: 26
Number of APNIC region 32-bit ASNs visible in the Routing Table:242
Number of APNIC addresses announced to Internet:  551407040
 Equivalent to 32 /8s, 221 /16s and 205 /24s
 Percentage of available APNIC address space announced: 64.4

APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
58368-59391, 131072-133119
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
 49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes: 96228
 Total ARIN prefixes after maximum aggregation:43322
 ARIN Deaggregation factor: 2.22
Prefixes being announced from the ARIN address blocks:97518
 Unique aggregates announced from the ARIN address blocks: 38278
ARIN Region origin ASes present in the Internet Routing Table:10585
 ARIN Prefixes per ASN: 9.21
ARIN Region origin ASes announcing only one prefix:4892
ARIN Region transit ASes present in the Internet Routing Table:1244
Average ARIN Region AS path length visible: 4.0
 Max ARIN Region AS path length visible:  24
Number of ARIN region 32-bit ASNs visible in the Routing Table:   7
Number 

Re: Weekly Routing Table Report

[Philip Smith]

Yup, the CIDR Report gets its feed in Australia...

I get my BGP feed from APNIC's router in Japan - and at the time it
grabbed the dump, the BGP table stopped at 190.55.80.0/21. Not sure
what's going on, looks like the ssh session just hung, but then
terminated normally - so the script's checking for hung sessions or
early disconnects didn't catch it.

Sorry folks...

philip
--

joel jaeggli said the following on 25/08/12 09:24 :
 On 8/24/12 3:07 PM, Lori Jakab wrote:
 On 8/24/2012 11:33 AM, Routing Analysis Role Account wrote:

 [...]

 Analysis Summary
 

 BGP routing table entries examined:  264582
 Isn't this supposed to be 400K? What happened this week?
 yes it disagrees with the cidr report.
 
 424791
 
 
 -Lori

  Prefixes after maximum aggregation:   97761
  Deaggregation factor:  2.71
  Unique aggregates announced to Internet: 119633
 Total ASes present in the Internet Routing Table: 29036
  Prefixes per ASN:  9.11
 Origin-only ASes present in the Internet Routing Table:   22245
 Origin ASes announcing only one prefix:   11565
 Transit ASes present in the Internet Routing Table:4486
 Transit-only ASes present in the Internet Routing Table:492
 Average AS path length visible in the Internet Routing Table:   4.6
  Max AS path length visible:  32
  Max AS path prepend of ASN ( 48687)  24
 Prefixes from unregistered ASNs in the Routing Table:   435
  Unregistered ASNs in the Routing Table: 144
 Number of 32-bit ASNs allocated by the RIRs:   3169
 Number of 32-bit ASNs visible in the Routing Table:2305
 Prefixes from 32-bit ASNs in the Routing Table:6164
 Special use prefixes present in the Routing Table:0
 Prefixes being announced from unallocated address space: 74
 Number of addresses announced to Internet:   2132781732
  Equivalent to 127 /8s, 31 /16s and 170 /24s
  Percentage of available address space announced:   57.5
  Percentage of allocated address space announced:   57.6
  Percentage of available address space allocated:   99.9
  Percentage of address space in use by end-sites:   93.3
 Total number of prefixes smaller than registry allocations:  117536

 APNIC Region Analysis Summary
 -

 Prefixes being announced by APNIC Region ASes:59813
  Total APNIC prefixes after maximum aggregation:   15336
  APNIC Deaggregation factor:3.90
 Prefixes being announced from the APNIC address blocks:   60438
  Unique aggregates announced from the APNIC address blocks:22879
 APNIC Region origin ASes present in the Internet Routing Table:2883
  APNIC Prefixes per ASN:   20.96
 APNIC Region origin ASes announcing only one prefix:806
 APNIC Region transit ASes present in the Internet Routing Table:609
 Average APNIC Region AS path length visible:4.7
  Max APNIC Region AS path length visible: 26
 Number of APNIC region 32-bit ASNs visible in the Routing Table:242
 Number of APNIC addresses announced to Internet:  551407040
  Equivalent to 32 /8s, 221 /16s and 205 /24s
  Percentage of available APNIC address space announced: 64.4

 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
 (pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079,
 55296-56319,
 58368-59391, 131072-133119
 APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
  49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
 222/8, 223/8,

 ARIN Region Analysis Summary
 

 Prefixes being announced by ARIN Region ASes: 96228
  Total ARIN prefixes after maximum aggregation:43322
  ARIN Deaggregation factor: 2.22
 Prefixes being announced from the ARIN address blocks:97518
  Unique aggregates announced from the ARIN address blocks: 38278
 ARIN 

Re: Weekly Routing Table Report

[Jared Mauch]

On Jul 25, 2012, at 10:16 PM, Geoff Huston g...@apnic.net wrote:

 
 On 21/07/2012, at 6:40 AM, Jared Mauch wrote:
 
 
 On Jul 20, 2012, at 4:30 PM, Ron Broersma wrote:
 
 
 On Jul 20, 2012, at 1:04 PM, valdis.kletni...@vt.edu wrote:
 On Sat, 21 Jul 2012 05:10:41 +1000, Routing Analysis Role Account said:
 BGP routing table entries examined:  418048
 So, whatever happened to that whole the internet will catch fire when
 we get to 280K routing table entries or whatever it was? :)
 
 We added memory where we could, or bought bigger routers.  The new 
 (conventional wisdom) limit is 1M routes.
 
 I think you mean 512k IPv4 with 256k of IPv6 (taking double space).
 
 512K of IPv4? That's getting close!

I know a few people had issues around the 256k barrier from tcam based 
platforms. Expect a lot of BGP instability as people react to 512k entries in 
their fib

Re: Weekly Routing Table Report

[Geoff Huston]

On 21/07/2012, at 6:40 AM, Jared Mauch wrote:

 
 On Jul 20, 2012, at 4:30 PM, Ron Broersma wrote:
 
 
 On Jul 20, 2012, at 1:04 PM, valdis.kletni...@vt.edu wrote:
 On Sat, 21 Jul 2012 05:10:41 +1000, Routing Analysis Role Account said:
 BGP routing table entries examined:  418048
 So, whatever happened to that whole the internet will catch fire when
 we get to 280K routing table entries or whatever it was? :)
 
 We added memory where we could, or bought bigger routers.  The new 
 (conventional wisdom) limit is 1M routes.
 
 I think you mean 512k IPv4 with 256k of IPv6 (taking double space).

512K of IPv4? That's getting close!

Geoff

Re: Weekly Routing Table Report

[valdis . kletnieks]

On Sat, 21 Jul 2012 05:10:41 +1000, Routing Analysis Role Account said:
 This is an automated weekly mailing describing the state of the Internet
 Routing Table as seen from APNIC's router in Japan.

 BGP routing table entries examined:  418048

So, whatever happened to that whole the internet will catch fire when
we get to 280K routing table entries or whatever it was? :)


pgpVUzSxg90ri.pgp
Description: PGP signature

Re: Weekly Routing Table Report

[Darius Jahandarie]

On Fri, Jul 20, 2012 at 4:04 PM,  valdis.kletni...@vt.edu wrote:
 So, whatever happened to that whole the internet will catch fire when
 we get to 280K routing table entries or whatever it was? :)

But what will happen when we have 4294967295 entries?


-- 
Darius Jahandarie

Re: Weekly Routing Table Report

[Patrick W. Gilmore]

On Jul 20, 2012, at 16:10 , Darius Jahandarie wrote:
 On Fri, Jul 20, 2012 at 4:04 PM,  valdis.kletni...@vt.edu wrote:
 So, whatever happened to that whole the internet will catch fire when
 we get to 280K routing table entries or whatever it was? :)
 
 But what will happen when we have 4294967295 entries?

Nothing.  But when we hit 4294967296

=)

-- 
TTFN,
patrick

Re: Weekly Routing Table Report

[Ron Broersma]

On Jul 20, 2012, at 1:04 PM, valdis.kletni...@vt.edu wrote:
 On Sat, 21 Jul 2012 05:10:41 +1000, Routing Analysis Role Account said:
 BGP routing table entries examined:  418048
 So, whatever happened to that whole the internet will catch fire when
 we get to 280K routing table entries or whatever it was? :)

We added memory where we could, or bought bigger routers.  The new 
(conventional wisdom) limit is 1M routes.




smime.p7s
Description: S/MIME cryptographic signature

Re: Weekly Routing Table Report

[Jared Mauch]

On Jul 20, 2012, at 4:30 PM, Ron Broersma wrote:

 
 On Jul 20, 2012, at 1:04 PM, valdis.kletni...@vt.edu wrote:
 On Sat, 21 Jul 2012 05:10:41 +1000, Routing Analysis Role Account said:
 BGP routing table entries examined:  418048
 So, whatever happened to that whole the internet will catch fire when
 we get to 280K routing table entries or whatever it was? :)
 
 We added memory where we could, or bought bigger routers.  The new 
 (conventional wisdom) limit is 1M routes.

I think you mean 512k IPv4 with 256k of IPv6 (taking double space).

Make sure you check your tcam profiles :)

- Jared

Re: Weekly Routing Table Report

[valdis . kletnieks]

On Fri, 20 Jul 2012 16:16:59 -0400, Patrick W. Gilmore said:
 On Jul 20, 2012, at 16:10 , Darius Jahandarie wrote:
  On Fri, Jul 20, 2012 at 4:04 PM,  valdis.kletni...@vt.edu wrote:
  So, whatever happened to that whole the internet will catch fire when
  we get to 280K routing table entries or whatever it was? :)
 
  But what will happen when we have 4294967295 entries?

 Nothing.  But when we hit 4294967296

By that point router vendors will hopefully have moved to 64-bit CPUs.
18446744073709551616 routes will hopefully not happen until after I retire,
so you young whippersnappers will be on your own on that one. ;)


pgpPOge1IU2CB.pgp
Description: PGP signature

Re: Weekly Routing Table Report

[Joel jaeggli]

On 7/20/12 13:40 , Jared Mauch wrote:
 
 On Jul 20, 2012, at 4:30 PM, Ron Broersma wrote:
 

 On Jul 20, 2012, at 1:04 PM, valdis.kletni...@vt.edu wrote:
 On Sat, 21 Jul 2012 05:10:41 +1000, Routing Analysis Role Account said:
 BGP routing table entries examined:  418048
 So, whatever happened to that whole the internet will catch fire when
 we get to 280K routing table entries or whatever it was? :)

 We added memory where we could, or bought bigger routers.  The new 
 (conventional wisdom) limit is 1M routes.
 
 I think you mean 512k IPv4 with 256k of IPv6 (taking double space).

if you're still on a platform with 40Mbit cams it's beginning look kinda
tight as an internet router. you've probably got less than a year to
figure out what to do about this.

an f10 ej linecard cam paritioning scheme for example looks something like.

CamSize : 40-Meg
: Current Settings
Profile Name: default
Microcode Name  : Default
L2FIB   : 15K entries
  Learn : 1K entries
L2ACL   : 5K entries
  System Flow   : 102 entries
  Qos   : 500 entries
  Frrp  : 102 entries
  L2pt  : 266 entries
  PPVlan: 100 entries
IPv4FIB : 512K entries
IPv4ACL : 16K entries
IPv4Flow: 24K entries
  Mcast Fib/Acl : 9K entries
  Pbr   : 1K entries
  Qos   : 10K entries
  System Flow   : 4K entries
EgL2ACL : 2K entries
EgIpv4ACL   : 4K entries
Mpls: 60K entries
IPv6FIB : 12K entries
IPv6ACL : 6K entries
IPv6Flow: 6K entries
  Mcast Fib/Acl : 3K entries
  Pbr   : 0K entries
  Qos   : 1K entries
  System Flow   : 2K entries
EgIpv6ACL   : 1K entries
GenEgACL: 0.5K entries
IPv4FHOP: 4K entries
IPv6FHOP: 4K entries
IPv4/IPv6NHOP   : 12K entries

 Make sure you check your tcam profiles :)
 
 - Jared
 
 
 

Re: Weekly Routing Table Report

[Mark Andrews]

In message cafanwtu_by8yxorlqeoywlmtrcdqp35cehhye1ryxt_ybet...@mail.gmail.com
, Darius Jahandarie writes:
 On Fri, Jul 20, 2012 at 4:04 PM,  valdis.kletni...@vt.edu wrote:
  So, whatever happened to that whole the internet will catch fire when
  we get to 280K routing table entries or whatever it was? :)
 
 But what will happen when we have 4294967295 entries?

We we long ago have switch to routers that are capable of handling
more or we will succeed in making multi homing work well enough
with PA addresses that we don't get there.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Weekly Routing Table Report

[Geoff Huston]

On 19/10/2011, at 9:02 PM, Philip Smith wrote:

 Hi Leo,
 
 Leo Vegoda said the following on 18/10/11 00:31 :
 
 128.0.87.0/2430977 JSC Yugra-Telecom
 
 This one seems to be an error. 128.0.80/21 appears to have been allocated on 
 5 October, nine days before the report was generated. 
 
 The report is as good as what is in the RIR allocation databases, as I
 grab those from the RIR public listings about 2 hours before the report
 is run. So if it was allocated, it wasn't listed in the file that I pick
 up. I'll investigate why.
 
 The report is not 100% accurate. Some of the resources listed do appear to 
 be used without being registered but not all of them.
 
 It is as accurate as the data I have access to. ;-) But I'd be delighted
 to hear suggestions for improvements.
 

You could try using http://bgp.potaroo.net/stats/nro/status.joint.txt

I use this as the basis of the bogon listing on the CIDR Report and I don't 
seem to be pickling up these false positives.

regards,

Geoff

Re: Weekly Routing Table Report

[Philip Smith]

Hi Leo,

Leo Vegoda said the following on 18/10/11 00:31 :

 128.0.87.0/2430977 JSC Yugra-Telecom
 
 This one seems to be an error. 128.0.80/21 appears to have been allocated on 
 5 October, nine days before the report was generated. 

The report is as good as what is in the RIR allocation databases, as I
grab those from the RIR public listings about 2 hours before the report
is run. So if it was allocated, it wasn't listed in the file that I pick
up. I'll investigate why.

 The report is not 100% accurate. Some of the resources listed do appear to be 
 used without being registered but not all of them.

It is as accurate as the data I have access to. ;-) But I'd be delighted
to hear suggestions for improvements.

philip
--

RE: Weekly Routing Table Report

[Leo Vegoda]

ML Wrote;
 On 10/14/2011 03:21 PM, Routing Analysis Role Account wrote:

[...]

  Prefixes from private and non-routed address space (Global)
  ---
 
  Prefix Origin AS  Description
  128.0.80.0/2430977 JSC Yugra-Telecom
  128.0.81.0/2430977 JSC Yugra-Telecom
  128.0.82.0/2430977 JSC Yugra-Telecom
  128.0.83.0/2430977 JSC Yugra-Telecom
  128.0.84.0/2430977 JSC Yugra-Telecom
  128.0.85.0/2430977 JSC Yugra-Telecom
  128.0.86.0/2430977 JSC Yugra-Telecom
  128.0.87.0/2430977 JSC Yugra-Telecom

This one seems to be an error. 128.0.80/21 appears to have been allocated on 5 
October, nine days before the report was generated. 

[...]

 Maybe I'm just not in the know on this but if these prefixes/ASes 
 shouldn't be seen on the internet, shouldn't there be more of a public 
 flogging to remove them?

The report is not 100% accurate. Some of the resources listed do appear to be 
used without being registered but not all of them.

Regards,

Leo

Re: Weekly Routing Table Report

[Hank Nussbacher]

On Fri, 14 Oct 2011, ML wrote:


On 10/14/2011 03:21 PM, Routing Analysis Role Account wrote:

 List of Unregistered Origin ASNs (Global)
 -
Maybe I'm just not in the know on this but if these prefixes/ASes shouldn't 
be seen on the internet, shouldn't there be more of a public flogging to 
remove them?


Been there.  Done that.  See from 2003:
http://www.nanog.org/meetings/nanog27/presentations/hank.pdf

I had been doing this for over a decade and gave up a few years ago. 
Bottom line: No one gives a sh*t.  Consider it all part of the background 
noise the Internet generates.


Regards,
Hank

Re: Weekly Routing Table Report

[ML]

On 10/14/2011 03:21 PM, Routing Analysis Role Account wrote:

List of Unregistered Origin ASNs (Global)
-

Bad AS  Designation  Network  Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24 7018   ATT WorldNet Servic
32567   UNALLOCATED  12.14.170.0/244323   Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/244323   Time Warner Telecom
25639   UNALLOCATED  12.41.169.0/247018   ATT WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24 7018   ATT WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24 7018   ATT WorldNet Servic
17300   UNALLOCATED  12.45.103.0/247018   ATT WorldNet Servic
17300   UNALLOCATED  12.45.110.0/24 701   UUNET Technologies,
16476   UNALLOCATED  12.46.27.0/24 7018   ATT WorldNet Servic
32873   UNALLOCATED  12.46.100.0/23   10912   InterNAP Network Ser

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
---

Prefix Origin AS  Description
128.0.80.0/2430977 JSC Yugra-Telecom
128.0.81.0/2430977 JSC Yugra-Telecom
128.0.82.0/2430977 JSC Yugra-Telecom
128.0.83.0/2430977 JSC Yugra-Telecom
128.0.84.0/2430977 JSC Yugra-Telecom
128.0.85.0/2430977 JSC Yugra-Telecom
128.0.86.0/2430977 JSC Yugra-Telecom
128.0.87.0/2430977 JSC Yugra-Telecom

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses


NetworkOrigin AS  Description
24.225.128.0/18  36377 Comcast Telecommunications, I
24.225.192.0/23  36377 Comcast Telecommunications, I
24.225.192.0/18  36377 Comcast Telecommunications, I
24.225.224.0/21  36377 Comcast Telecommunications, I
24.225.237.0/24  36377 Comcast Telecommunications, I
24.225.248.0/21  36377 Comcast Telecommunications, I
41.222.79.0/24   36938UNKNOWN
41.223.92.0/22   36936UNKNOWN
62.61.220.0/24   24974 Tachyon Europe BV - Wireless
62.61.221.0/24   24974 Tachyon Europe BV - Wireless

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA



Maybe I'm just not in the know on this but if these prefixes/ASes 
shouldn't be seen on the internet, shouldn't there be more of a public 
flogging to remove them?

Re: Weekly Routing Table Report

[Robert Kisteleki]

On 2011.03.19. 23:40, Geoff Huston wrote:
 
 On 19/03/2011, at 6:08 AM, Mikael Abrahamsson wrote:
 
 On Sat, 19 Mar 2011, Routing Analysis Role Account wrote:

 Number of 32-bit ASNs allocated by the RIRs:   1207
 Prefixes from 32-bit ASNs in the Routing Table:   1

 Is the report not getting the routes from the real 32bit ASNs or is the 
 above figures really accurate?
 
 Its probably not getting the routes - I see 915 AS's in the routing table 
 using 32 bit AS numbers (http://www.potaroo.net/tools/asn32/)
 
   Geoff

In RIS we saw 918 32 bit ASNs advertising about 2200 prefixes on 2011-03-19.

Robert

Re: Weekly Routing Table Report

[Geoff Huston]

On 19/03/2011, at 6:08 AM, Mikael Abrahamsson wrote:

 On Sat, 19 Mar 2011, Routing Analysis Role Account wrote:
 
 Number of 32-bit ASNs allocated by the RIRs:   1207
 Prefixes from 32-bit ASNs in the Routing Table:   1
 
 Is the report not getting the routes from the real 32bit ASNs or is the above 
 figures really accurate?

Its probably not getting the routes - I see 915 AS's in the routing table using 
32 bit AS numbers (http://www.potaroo.net/tools/asn32/)

  Geoff

Re: Weekly Routing Table Report

[Mikael Abrahamsson]

On Sat, 19 Mar 2011, Routing Analysis Role Account wrote:


Number of 32-bit ASNs allocated by the RIRs:   1207
Prefixes from 32-bit ASNs in the Routing Table:   1


Is the report not getting the routes from the real 32bit ASNs or is the 
above figures really accurate?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Weekly Routing Table Report

[Franck Martin]

Would it not be time, to have the IPv6 equivalent of this table report?

5% of the Internet is IPv6, that's an interesting threshold that was just 
passed.

- Original Message -
From: Routing Analysis Role Account csc...@apnic.net
To: ap...@apops.net, nanog@nanog.org, routing...@ripe.net, af...@afnog.org, 
aus...@ausnog.net, sa...@sanog.org
Sent: Saturday, 17 April, 2010 6:10:56 AM
Subject: Weekly Routing Table Report

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.apnic.net.

If you have any comments please contact Philip Smith
pfsi...@gmail.com.

Routing Table Report 04:00 +10GMT Sat 17 Apr, 2010

Report Website: http://thyme.apnic.net
Detailed Analysis: http://thyme.apnic.net/current/

Analysis Summary

Re: Weekly Routing Table Report

[Zaid Ali]

On 4/16/10 11:28 AM, Franck Martin fra...@genius.com wrote:

 Would it not be time, to have the IPv6 equivalent of this table report?
 
 5% of the Internet is IPv6, that's an interesting threshold that was just
 passed.

I think that time has come :)

Zaid

Re: Weekly Routing Table Report

[Patrick W. Gilmore]

On Aug 7, 2009, at 2:13 PM, Routing Analysis Role Account wrote:

BGP routing table entries examined:   
293130


By at least one count, we are still below 300K.

--
TTFN,
patrick

Re: Weekly Routing Table Report

[Zartash Uzmi]

Apologies if this is too naive to ask but is there some detail available
about the items listed in the summary?

1) In particular, what exactly is the difference between the BGP routing
table entries examined (292961) and Unique aggregates announced to
Internet (145391)?

2) I believe 292961 is the worst case routing table size for any router. If
the unique aggregates announced to the Internet is 145391, how does the
routing table size anywhere may exceeds this number? Is the word Internet
the key here?

3) Is aggregation done at a particular router for (i) reducing the table
size in that router, or (ii) reducing the number of announced prefixes by
that router, or (iii) both?

Zartash

On Fri, Jul 31, 2009 at 11:12 PM, Routing Analysis Role Account 
csc...@apnic.net wrote:

 This is an automated weekly mailing describing the state of the Internet
 Routing Table as seen from APNIC's router in Japan.
 Daily listings are sent to bgp-st...@lists.apnic.net

 For historical data, please see http://thyme.apnic.net.

 If you have any comments please contact Philip Smith p...@cisco.com.

 Routing Table Report   04:00 +10GMT Sat 01 Aug, 2009

 Report Website: http://thyme.apnic.net
 Detailed Analysis:  http://thyme.apnic.net/current/

 Analysis Summary
 

 BGP routing table entries examined:  292961
Prefixes after maximum aggregation:  138493
Deaggregation factor:  2.12
Unique aggregates announced to Internet: 145391
 Total ASes present in the Internet Routing Table: 31852
Prefixes per ASN:  9.20
 Origin-only ASes present in the Internet Routing Table:   27681
 Origin ASes announcing only one prefix:   13518
 Transit ASes present in the Internet Routing Table:4171
 Transit-only ASes present in the Internet Routing Table:105
 Average AS path length visible in the Internet Routing Table:   3.6
Max AS path length visible:  24
Max AS path prepend of ASN (12026)   22
 Prefixes from unregistered ASNs in the Routing Table:   456
Unregistered ASNs in the Routing Table: 130
 Number of 32-bit ASNs allocated by the RIRs:220
 Prefixes from 32-bit ASNs in the Routing Table:  81
 Special use prefixes present in the Routing Table:0
 Prefixes being announced from unallocated address space:340
 Number of addresses announced to Internet:   2082757696
Equivalent to 124 /8s, 36 /16s and 92 /24s
Percentage of available address space announced:   56.2
Percentage of allocated address space announced:   65.0
Percentage of available address space allocated:   86.4
Percentage of address space in use by end-sites:   78.5
 Total number of prefixes smaller than registry allocations:  140414

 APNIC Region Analysis Summary
 -

 Prefixes being announced by APNIC Region ASes:70058
Total APNIC prefixes after maximum aggregation:   24829
APNIC Deaggregation factor:2.82
 Prefixes being announced from the APNIC address blocks:   69476
Unique aggregates announced from the APNIC address blocks:31605
 APNIC Region origin ASes present in the Internet Routing Table:3717
APNIC Prefixes per ASN:   18.69
 APNIC Region origin ASes announcing only one prefix:   1012
 APNIC Region transit ASes present in the Internet Routing Table:579
 Average APNIC Region AS path length visible:3.5
Max APNIC Region AS path length visible: 16
 Number of APNIC addresses announced to Internet:  475903680
Equivalent to 28 /8s, 93 /16s and 182 /24s
Percentage of available APNIC address space announced: 88.6

 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
 (pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079
 APNIC Address Blocks58/8,  59/8,  60/8,  61/8, 110/8, 111/8, 112/8,
   113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8,
   120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8,
   180/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8,
   219/8, 220/8, 221/8, 222/8,

 ARIN Region Analysis Summary
 

 Prefixes being announced by ARIN Region ASes:124431
Total ARIN prefixes after maximum aggregation:66173
ARIN Deaggregation factor: 1.88
 Prefixes being announced from the ARIN