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 simpl
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
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 ar
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
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 origin
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
>
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
> 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.
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
> 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
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/
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,
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 b
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 verifi
--- 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/R
> 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 sign
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 netw
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
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 o
> 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...
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.a
> There are other articles, some of which are peer reviewed papers,
> describing details.
Can you link those?
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.
Rea
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
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 multi
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
> 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.
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::/4
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 fund
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
t
> 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
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.
thi
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
communic
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
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
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 no
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
> 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
> 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 i
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
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...@the
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
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 int
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...
--- 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
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 s
gt;> 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
>>
&g
rican 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 d
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 comment
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 expe
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 th
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?
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 Slabber
-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
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?
--
Hug
On Sep 20, 2013, at 2:51 PM, Routing Analysis Role Account
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
>
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
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 t
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:
On Jul 25, 2012, at 10:16 PM, Geoff Huston 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
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:
In message
, Darius Jahandarie writes:
> On Fri, Jul 20, 2012 at 4:04 PM, 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
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:
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, wrote:
> >> So, whatever happened to that whole "the internet will catch fire when
> >> we get to 280K routing table entries" or whatever it
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
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
On Jul 20, 2012, at 16:10 , Darius Jahandarie wrote:
> On Fri, Jul 20, 2012 at 4:04 PM, 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?
Not
On Fri, Jul 20, 2012 at 4:04 PM, 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
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
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 repo
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 R
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 "
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
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 AT&T WorldNet Servic
32567 UN
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:
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
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 reall
On 4/16/10 11:28 AM, "Franck Martin" 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
On Fri, Apr 16, 2010 at 1:28 PM, Franck Martin wrote:
> Would it not be time, to have the IPv6 equivalent of this table report?
+1
It wold be nice to see how things gradually change as the 5% becomes larger.
Cheers
Jorge
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"
To: ap...@apops.net, nanog@nanog.org, routing...@ripe.net, af...@afnog.org
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
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
On Sun, 24 Feb 2008 12:39:42 +1100
Geoff Huston <[EMAIL PROTECTED]> wrote:
> http://www.cidr.report.org
I'm guessing that should be
http://www.cidr-report.org/
--
"Sheep are slow and tasty, and therefore must remain constantly
alert."
- Bru
83 matches
Mail list logo
