Mailing List Archive

1 2 3  View All
Re: Weekly Routing Table Report [ In reply to ]
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 [ In reply to ]
> On Aug 31, 2019, at 05:04, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> 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 50000 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 [ In reply to ]
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.
Re: Weekly Routing Table Report [ In reply to ]
Owen DeLong wrote:

>>> However, since you don$B!G(Bt like Comcast, let$B!G(Bs 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 [ In reply to ]
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 [ In reply to ]
> On Aug 31, 2019, at 18:48 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> 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 [ In reply to ]
--- mohta@necom830.hpcl.titech.ac.jp wrote:
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
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 [ In reply to ]
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 [ In reply to ]
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 <
mohta@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 [ In reply to ]
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 [ In reply to ]
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 <
mohta@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 [ In reply to ]
> On Sep 2, 2019, at 9:33 AM, Tony Finch <dot@dotat.at> wrote:
>
> Patrick W. Gilmore <patrick@ianai.net> 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 [ In reply to ]
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)
Re: Weekly Routing Table Report [ In reply to ]
> On 2. Sep 2019, at 15:49, Valdis Kl?tnieks <valdis.kletnieks@vt.edu> 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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
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 [ In reply to ]
On Sat, 31 Aug 2019 10:35:39 +0000
Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> 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 [ In reply to ]
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&action=DownLoad&file=201904901-2662-0-35.pdf&type=cal&JWC=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

1 2 3  View All