Re: Weekly Routing Table Report

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

Re: Weekly Routing Table Report

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",

Re: Weekly Routing Table Report

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

Re: Weekly Routing Table Report

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.

Re: Weekly Routing Table Report

> 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?

Re: Weekly Routing Table Report

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

Re: Weekly Routing Table Report

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

Re: Weekly Routing Table Report

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

Re: Weekly Routing Table Report

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

Re: Weekly Routing Table Report

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

RE: Weekly Routing Table Report

> 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

Re: Weekly Routing Table Report

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

Re: Weekly Routing Table Report

> 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

Re: 44/8

On 8/27/19 8:52 PM, Owen DeLong wrote: On Jul 26, 2019, at 21:59 , Doug Barton > wrote: Responding to no one in particular, and not representing views of any current or former employer ... I find all of this hullabaloo to be ... fascinating. A little

Re: Weekly Routing Table Report

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.

Re: Weekly Routing Table Report

> There are other articles, some of which are peer reviewed papers, > describing details. Can you link those?

Re: Weekly Routing Table Report

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:

Re: Weekly Routing Table Report

> 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?

Re: Weekly Routing Table Report

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

Re: Weekly Routing Table Report

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,

Re: Weekly Routing Table Report

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

Re: Weekly Routing Table Report

> 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

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

Re: Weekly Routing Table Report

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

Re: Weekly Routing Table Report

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