Re: IPv6 woes - RFC

2021-09-14 Thread Masataka Ohta
Valdis Klētnieks wrote: Not. With geographical aggregation, you may route a call *anywhere* in the destination country. The *real* fun starts when my provider is able to connect calls to my +1 540 etcetc phone number to my phone even if I'm in +371 or +81 or similar No problem. The calle

Re: IPv6 woes - RFC

2021-09-14 Thread Valdis Klētnieks
On Wed, 15 Sep 2021 13:38:21 +0900, Masataka Ohta said: > Not. With geographical aggregation, you may route a call > *anywhere* in the destination country. The *real* fun starts when my provider is able to connect calls to my +1 540 etcetc phone number to my phone even if I'm in +371 or +81 or si

Re: IPv6 woes - RFC

2021-09-14 Thread Masataka Ohta
Christopher Morrow wrote: NSAP addresses, which essentially are telephone numbers, assume geographically aggregated addresses at country level (so called, country code), which is why they don't need large global routing tables. The phone network doesn't really operate or 'route' in the same w

Re: IPv6 woes - RFC

2021-09-14 Thread Masataka Ohta
Shane Ronan wrote: But in fact with local number portability, you cannot rely on the county code to tell you where to route a telephone call anymore. Not. With geographical aggregation, you may route a call *anywhere* in the destination country. Geographical aggregation means carriers in a co

Re: IPv6 woes - RFC

2021-09-14 Thread Owen DeLong via NANOG
> On Sep 14, 2021, at 14:20 , Michael Thomas wrote: > > > On 9/14/21 2:07 PM, Owen DeLong wrote: >> You’d be surprised… Vendors often get well down a path before exposing >> enough information to the community to get the negative feedback their >> solution so richly deserves. At that point,

Re: IPv6 woes - RFC

2021-09-14 Thread Michael Thomas
On 9/14/21 2:17 PM, Randy Bush wrote: Just because I didn't attend IETF meetings doesn't mean that I didn't read drafts, etc. Lurkers are a thing and lurkers are allowed opinions too. i missed the rfc where the chair of the v6 wg said the ops did not understand the h ratio because we did not u

Re: IPv6 woes - RFC

2021-09-14 Thread Michael Thomas
On 9/14/21 2:07 PM, Owen DeLong wrote: You’d be surprised… Vendors often get well down a path before exposing enough information to the community to get the negative feedback their solution so richly deserves. At that point, they have rather strong incentives to push for the IETF adopting the

Re: IPv6 woes - RFC

2021-09-14 Thread Randy Bush
> Just because I didn't attend IETF meetings doesn't mean that I didn't > read drafts, etc. Lurkers are a thing and lurkers are allowed opinions > too. i missed the rfc where the chair of the v6 wg said the ops did not understand the h ratio because we did not understand logarithms. randy

Re: IPv6 woes - RFC

2021-09-14 Thread Michael Thomas
On 9/14/21 2:08 PM, Randy Bush wrote: I wasn't there at actual meetings at the time but your opinion was? Just because I didn't attend IETF meetings doesn't mean that I didn't read drafts, etc. Lurkers are a thing and lurkers are allowed opinions too. Mike

Re: IPv6 woes - RFC

2021-09-14 Thread Randy Bush
> I wasn't there at actual meetings at the time but your opinion was? > but I find the notion that operators were ignored pretty preposterous > too so did we, the ops who were there at the time randy

Re: IPv6 woes - RFC

2021-09-14 Thread Owen DeLong via NANOG
> On Sep 14, 2021, at 13:51 , Michael Thomas wrote: > > > > On 9/14/21 1:06 PM, Owen DeLong wrote: >> >> >>> On Sep 14, 2021, at 12:58 , Michael Thomas >> > wrote: >>> >>> >>> >>> On 9/14/21 5:37 AM, Eliot Lear wrote: 8+8 came MUCH later than that, and really w

Re: IPv6 woes - RFC

2021-09-14 Thread Michael Thomas
On 9/14/21 1:06 PM, Owen DeLong wrote: On Sep 14, 2021, at 12:58 , Michael Thomas > wrote: On 9/14/21 5:37 AM, Eliot Lear wrote: 8+8 came *MUCH* later than that, and really wasn't ready for prime time.  The reason we know that is that work was the basis of LISP and

Re: IPv6 woes - RFC

2021-09-14 Thread Shane Ronan
But in fact with local number portability, you cannot rely on the county code to tell you where to route a telephone call anymore. Which is many calls result in a data dip to provide you the routing information from a central repository. Shane On Tue, Sep 14, 2021 at 10:07 AM Masataka Ohta < mo..

Re: IPv6 woes - RFC

2021-09-14 Thread Christopher Morrow
On Tue, Sep 14, 2021 at 10:03 AM Masataka Ohta < mo...@necom830.hpcl.titech.ac.jp> wrote: > > NSAP addresses, which essentially are telephone numbers, assume > geographically aggregated addresses at country level (so called, > country code), which is why they don't need large global routing > tabl

Re: IPv6 woes - RFC

2021-09-14 Thread Owen DeLong via NANOG
> On Sep 14, 2021, at 12:58 , Michael Thomas wrote: > > > > On 9/14/21 5:37 AM, Eliot Lear wrote: >> 8+8 came MUCH later than that, and really wasn't ready for prime time. The >> reason we know that is that work was the basis of LISP and ILNP. Yes, >> standing on the shoulders of giants.

Re: IPv6 woes - RFC

2021-09-14 Thread Michael Thomas
On 9/14/21 5:37 AM, Eliot Lear wrote: 8+8 came *MUCH* later than that, and really wasn't ready for prime time.  The reason we know that is that work was the basis of LISP and ILNP.  Yes, standing on the shoulders of giants.  And there certainly were poor design decisions in IPv6, bundling IP

Re: IPv6 woes - RFC

2021-09-14 Thread Masataka Ohta
Eliot Lear wrote: Operators and router manufacturers at the time pushed TUBA, which was considerably less compatible with the concepts used in v4 because of variable length addressing. That address length is variable is not a problem at all. Byte-wise barrel shifters by hardware for CLNP are

Re: IPv6 woes - RFC

2021-09-14 Thread Masataka Ohta
Nick Hilliard wrote: E.g. using mcast for address resolution because large flat l2 networks were the order of the day, It was and still is trivially obvious that automatic address resolution over large flat l2 does not scale. Configuring virtual all-host-mcast in large flat l2 for automatic a

Re: IPv6 woes - RFC

2021-09-14 Thread Eliot Lear
8+8 came *MUCH* later than that, and really wasn't ready for prime time.  The reason we know that is that work was the basis of LISP and ILNP.  Yes, standing on the shoulders of giants.  And there certainly were poor design decisions in IPv6, bundling IPsec being one.  But the idea that operato

Re: IPv6 woes - RFC

2021-09-14 Thread Randy Bush
and 8+8, variable length, ... just didn't happen, eh? the nice thing about revisionist history is that anybody can play. randy

Re: IPv6 woes - RFC

2021-09-14 Thread Masataka Ohta
Randy Bush wrote: it took five years of war to get rid of the tla/sla crap. As backbone operators do not want to have large routing tables, TLA is a good idea. As you can see, TLA of IPv4 is /24, though there is no NLA. and look at the /64 religion today[0]. It was /80, until I pointed out

Re: IPv6 woes - RFC

2021-09-14 Thread Eliot Lear
On 13.09.21 20:22, Randy Bush wrote: < rant > ipv6 was designed at a time where the internet futurists/idealists had disdain for operators and vendors, and thought we were evil money grabbers who had to be brought under control. and... real compatibility with ipv4 was disdained. I'