Mailing List Archive

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 that IEEE1394 MAC
address is 64bit long.

Masataka Ohta

and 8+8, variable length, ... just didn't happen, eh?

the nice thing about revisionist history is that anybody can play.

randy

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 operators were ignored?  Feh.

On 14.09.21 14:10, Randy Bush wrote:
> and 8+8, variable length, ... just didn't happen, eh?
>
> the nice thing about revisionist history is that anybody can play.
>
> randy
>

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 address resolution needs static address
resolution information, which is not automatic.

> that client
> self-selected addresses should be the only game in town for
> auto-addressing

Using lengthy MAC addresses for that purpose was tried
in XNS. But as it was so annoying, it was totally abandoned
at the time IPv4 was widely developed.

Though AppleTalk was still using a single byte for that
purpose in SOHO, DHCP was already performing better
everywhere including SOHO.

> that extension headers were a great idea,

IPv4 optional header was totally operationally denied a lot
before that.

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 trivially easy and light
weight to implement.

The real problem is on the number of prefix bits which must be
looked up by backbone routers, which means IPv6 abandoning TLA
is hopeless.

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.

8+8 has nothing to do with the problem and LISP came a lot later
as a broken solution for the problem.

Masataka Ohta

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 IPsec being one.  But the
> idea that operators were ignored?  Feh.
>
I wasn't there at actual meetings at the time but I find the notion that
operators were ignored pretty preposterous too. There was a significant
amount of bleed over between the two as I recall from going to
Interop's. What incentive do vendors have to ignore their customers?
Vendors have incentive to listen to customer requirements and abstract
them to take into account things can't see on the outside, but to
actually give the finger to them? And given how small the internet
community was back while this was happening, I find it even more unlikely.

But Randy still hasn't told us what would have worked and why it would
have succeeded.

Mike


> On 14.09.21 14:10, Randy Bush wrote:
>> and 8+8, variable length, ... just didn't happen, eh?
>>
>> the nice thing about revisionist history is that anybody can play.
>>
>> randy
>>

> On Sep 14, 2021, at 12:58 , Michael Thomas <mike@mtcc.com> 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. And there certainly were poor design decisions in IPv6, bundling IPsec being one. But the idea that operators were ignored? Feh.
>>
> I wasn't there at actual meetings at the time but I find the notion that operators were ignored pretty preposterous too. There was a significant amount of bleed over between the two as I recall from going to Interop's. What incentive do vendors have to ignore their customers? Vendors have incentive to listen to customer requirements and abstract them to take into account things can't see on the outside, but to actually give the finger to them? And given how small the internet community was back while this was happening, I find it even more unlikely.
>

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 their solution over customer objections because of entrenched code-base and a desire not to go back and explain to management that the idea they’ve been working on for the last 6 months is stillborn.

Owen

On Tue, Sep 14, 2021 at 10:03 AM Masataka Ohta <
mohta@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
> tables.
>

The phone network doesn't really operate or 'route' in the same way as the
Internet does.
I don't think using it in a comparison here works, at all... I really wish
folk would stop trying
to make this equivalency.

(I think LNP actually means the phone carriers are creating a 'must know
about 6+b address/path mappings
in a possible future... or even just in the US ~350m endpoints/mappings,
but anyways...)

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 <
mohta@necom830.hpcl.titech.ac.jp> wrote:

> 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 trivially easy and light
> weight to implement.
>
> The real problem is on the number of prefix bits which must be
> looked up by backbone routers, which means IPv6 abandoning TLA
> is hopeless.
>
> 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.
>
> 8+8 has nothing to do with the problem and LISP came a lot later
> as a broken solution for the problem.
>
> Masataka Ohta
>

On 9/14/21 1:06 PM, Owen DeLong wrote:
>
>
>> On Sep 14, 2021, at 12:58 , Michael Thomas <mike@mtcc.com
>> <mailto:mike@mtcc.com>> 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. And there
>>> certainly were poor design decisions in IPv6, bundling IPsec being
>>> one.  But the idea that operators were ignored?  Feh.
>>>
>> I wasn't there at actual meetings at the time but I find the notion
>> that operators were ignored pretty preposterous too. There was a
>> significant amount of bleed over between the two as I recall from
>> going to Interop's. What incentive do vendors have to ignore their
>> customers? Vendors have incentive to listen to customer requirements
>> and abstract them to take into account things can't see on the
>> outside, but to actually give the finger to them? And given how small
>> the internet community was back while this was happening, I find it
>> even more unlikely.
>>
>
> 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 their solution over customer
> objections because of entrenched code-base and a desire not to go back
> and explain to management that the idea they’ve been working on for
> the last 6 months is stillborn.
>
But we're talking almost 30 years ago when the internet was tiny. And
it's not like operators were some fount of experience and wisdom back
then: everybody was making it up along the way including operators which
barely even existed back then. I mean, we're talking about the netcom
days here. That's why this stinks of revisionist history to me.

Mike

> On Sep 14, 2021, at 13:51 , Michael Thomas <mike@mtcc.com> wrote:
>
>
>
> On 9/14/21 1:06 PM, Owen DeLong wrote:
>>
>>
>>> On Sep 14, 2021, at 12:58 , Michael Thomas <mike@mtcc.com <mailto:mike@mtcc.com>> 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. And there certainly were poor design decisions in IPv6, bundling IPsec being one. But the idea that operators were ignored? Feh.
>>>>
>>> I wasn't there at actual meetings at the time but I find the notion that operators were ignored pretty preposterous too. There was a significant amount of bleed over between the two as I recall from going to Interop's. What incentive do vendors have to ignore their customers? Vendors have incentive to listen to customer requirements and abstract them to take into account things can't see on the outside, but to actually give the finger to them? And given how small the internet community was back while this was happening, I find it even more unlikely.
>>>
>>
>> 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 their solution over customer objections because of entrenched code-base and a desire not to go back and explain to management that the idea they’ve been working on for the last 6 months is stillborn.
>>
> But we're talking almost 30 years ago when the internet was tiny. And it's not like operators were some fount of experience and wisdom back then: everybody was making it up along the way including operators which barely even existed back then. I mean, we're talking about the netcom days here. That's why this stinks of revisionist history to me.
>

I was there for parts of it. Even then, the vendors were entrenched in their views and dominated many of the conversations.

Owen

> 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

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

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

<plonk>

randy

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 their solution over customer
> objections because of entrenched code-base and a desire not to go back
> and explain to management that the idea they’ve been working on for
> the last 6 months is stillborn.
>>>
>> But we're talking almost 30 years ago when the internet was tiny. And
>> it's not like operators were some fount of experience and wisdom back
>> then: everybody was making it up along the way including operators
>> which barely even existed back then. I mean, we're talking about the
>> netcom days here. That's why this stinks of revisionist history to me.
>>
>
> I was there for parts of it. Even then, the vendors were entrenched in
> their views and dominated many of the conversations.
>
Vendors have to be able to implement things so of course there is going
to be push back when it's not technically feasible or far more
expensive. Nobody expects customers putting out the actual $$$ to be up
to speed on the intricacies of TCAM's and other such considerations so
there is always going to be back and forth.

And none of this alters that nobody has given a scenario where their
$SOLUTION would have fared any better than ipv6.

Mike

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 understand logarithms.

So in order to have an opinion, I have to know all of the politics along
with the documents produced. Got it. Thank goodness we didn't know that
when we were implementing IPv4 in the mid 80's.

Frankly I had always regretted not going to an IETF meeting at ISI
around 88 or so, but given the silliness of IETF politics maybe that was
a blessing.

Mike

> On Sep 14, 2021, at 14:20 , Michael Thomas <mike@mtcc.com> 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, they have rather strong incentives to push for the IETF adopting their solution over customer objections because of entrenched code-base and a desire not to go back and explain to management that the idea they’ve been working on for the last 6 months is stillborn.
>>>>
>>> But we're talking almost 30 years ago when the internet was tiny. And it's not like operators were some fount of experience and wisdom back then: everybody was making it up along the way including operators which barely even existed back then. I mean, we're talking about the netcom days here. That's why this stinks of revisionist history to me.
>>>
>>
>> I was there for parts of it. Even then, the vendors were entrenched in their views and dominated many of the conversations.
>>
> Vendors have to be able to implement things so of course there is going to be push back when it's not technically feasible or far more expensive. Nobody expects customers putting out the actual $$$ to be up to speed on the intricacies of TCAM's and other such considerations so there is always going to be back and forth.

Back and forth is one thing, but the reality is that they put a lot of development effort into things in a vacuum and then expected us to take what they built and standardize it. They often seemed utterly surprised when the practical realities of deploying it in an operational network didn’t agree with their idea of an “elegant” solution.

> And none of this alters that nobody has given a scenario where their $SOLUTION would have fared any better than ipv6.

That’s probably fair criticism to some extent.

Owen

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 country is
required to have rich and robust connectivity between
them within the country as if the country is served by
a single carrier, which actually was the case with
ATT/PTT/NTT monopoly.

Then, whichever international carrier is chosen by the caller,
the international carrier looks up country-wise routing
table to reach the country. When the call reaches some
point in the destination country, the callee can be reached
relying on rich connectivity in the country.

Number portability database is looked up after the call
reaches the destination country, which will be used for
further intra-national routing, which do not affect
country-wise aggregation of international routing table.

But, as ISPs do not want to be regulated to have such rich
intra-national connectivity in all the countries,
geographically aggregated addressing is considered not
acceptable by operator community of the Internet.

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 way as the
> Internet does.

The context here is TUBA where NSAP addresses are used for best
effort CLNP, which is not circuit switched and resource reserving
phone network.

> I don't think using it in a comparison here works, at all... I really wish
> folk would stop trying
> to make this equivalency.

That you don't properly understand the similarities and the
differences between telephone network and the Internet is
not a problem for rest of us.

Masataka Ohta

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 similar....

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 caller will be charged for call to +1 and you
will be charged for international transfer from +1 to +371 or
+81.

Masataka Ohta

On Wed, 15 Sept 2021 at 06:38, Masataka Ohta <
mohta@necom830.hpcl.titech.ac.jp> wrote:

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

You mean anywhere in the world. Calls to my number reach my cell phone no
matter where I go.


>
> Number portability database is looked up after the call
> reaches the destination country, which will be used for
> further intra-national routing, which do not affect
> country-wise aggregation of international routing table.
>
>
Actually the GSM system will query the HLR to find out where to really
route the call. Much like LISP actually.

Regards,

Baldur

On 15.09.21 06:38, Masataka Ohta wrote:
>
> Geographical aggregation means carriers in a country is
> required to have rich and robust connectivity between
> them within the country...

or region.

And this is indeed why such an addressing concept was dropped from
IPv6.  It just didn't fly economically.

Eliot

Baldur Norddahl 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.

> You mean anywhere in the world. Calls to my number reach my cell phone no
> matter where I go.

You are confusing number portability and call forwarding.

Masataka Ohta

On 9/15/21 09:31, Masataka Ohta wrote:
> Baldur Norddahl 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.
>
>> You mean anywhere in the world. Calls to my number reach my cell phone no
>> matter where I go.
>
> You are confusing number portability and call forwarding.

You're confusing call forwarding with international roaming.

Obligatory back story. In the early days of international roaming I had
cellular service in the US with AT&T. I traveled to Bulgaria for a week
and took my phone with me. International rates were on the order of
$3.95 per minute.

I deliberately left my phone turned off so as to avoid expensive
incoming calls. On arrival I turned my phone on and made two calls to
let people at home know I'd arrived. During the trip I would turn it on
and make a call occasionally, total under ten calls, all outbound.

When I got home I would up with a bill totaling several hundred dollars.
Every time someone called my number the call got routed to Bulgaria. The
call then went back to the USA and hit my voicemail, so I got charged
$3.95 twice for each of these calls.

I eventually got the bill resolved, but it took a very long time and
multiple escalations. Suffice it to say that AT&T customer service reps
are located nowhere near the "A" in "AT&T".

A year later I made another international trip. Ahead of time I called
AT&T to ask them to disable voicemail so I wouldn't have to deal with
that again. I finally was able to do so but that, too, took multiple
calls to people very obviously not in "A".

--
Jay Hennigan - jay@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV