Re: [v6ops] RFC7849 must not recommend 64share, and must not be recommended itself to 3GPP

[Alexandre Petrescu <[e-mail]>]

Le 03/03/2017 à 17:09, Ca By a écrit :
>
> On Fri, Mar 3, 2017 at 5:54 AM Alexandre Petrescu
> <[e-mail] <mailto:[e-mail]>>
>  wrote:
>
>
>
> Le 03/03/2017 à 14:43, Erik Kline a écrit :
>>
>> Because Prefix Delegation capabilities may not be available in
>> some attached networks, L_REC#1 is strongly recommended to
>> accommodate early deployments. =====
>>
>>
>> This is wrong.  We should _never_ recommend somehting we know it
>> does not scale.  64share does not scale, there is a 'multi-link
>> subnets' RFC and there is operational experience showing so.
>>
>>
>> False.
>>
>> We wrote IPv6 tethering in Android N (MR1), it uses 64share, and
>> it pretty much works just fine.
>
> Works fine but does is scale?
>
>
> Yes, millions of users

Well, I did not ask about scaling in terms of how many times can you
copy the same software on how many devices, or how many human users can
buy smartphones from same operator.  I agree 64share (like most other
sw) can scale to millions of devices sold to millions of users as part
of some subscription plans.

I asked about scaling in terms of IP networking.

I dont want _your_ network to grow, I want the end user's network to
grow.  And your network must not prevent the end user's network from
growing.

64share prevents your end users' networks from growing.

So, while millions of users is good, I look more at like billions of
devices connected to these millions of users.

> (apple and android) on many networks use what is described in
> 64share.

It is good that apple and android implement that software.

But that alone does not make it more recommendable than a plethora of
other software, starting from the simplest 'Hello World'.

> 64share describes 100% of the cases where users get ipv6 addresses
> via 3gpp phone tether afaik.

Yes, 64share RFC describes use-cases where it's relevant.

But I guess, as you write below about bicycles, 64share does not
care about, well, bicycles.

And the bicycles are different than smartphones.

As such, I dont understand why pushing 64share into 3GPP, when 3GPP
cares not only about smartphones, but also about IoTs like bicycles.

As such, I dont understand why making 64share into a recommendation to 3GPP.

More refinement should be there.

> Spare me the discussion about how the dongle ....

Well - you dont care about dongles, I do.

I will spare you.

But you will have to change the way you think of your end users.  They
wont spare you about their dongles, M2M devices and other IoTs.

> I am unaware of any network or mainstream smartphone that supports
> dhcp-pd.

Dont you think that the question of whether or not DHCP-PD runs ok on
smartphone is irrelevant?  DHCP-PD is open source software, can compile
anywhere.

Assume DHCPv6-PD app runs ok on smartphone.

And that does not make the operator respond and deliver prefixes.  They
dont care about a smartphone running or not the DHCPv6-PD.  They care
about what 3GPP asks.  And 3GPP asks what this RFC says.  And this RFC
says no need of DHCP because do 64share.  That's not normal.

> I am sure you can rig something up, but i am simply referring to your
> comment of scale in the real world for todays use cases.

Ah, let me clarify my comment of scale.

I am concerned with scaling beyond 2 subnets: up to 45 subnets in 15
cars, and 10 subnets in 5 Road-Side Units, in a city center area.  And
that's the lowest number I could go with.

64share cant scale to that.  Do you agree?

This may be 'rigging up' for you, but for me it is more serious.

> This is ietf, running code matters. Deployments matter even more.

I agree.

But in this case it seems what you believe your smartphone deployment
should prime over what non-smartphone (e.g. bicycle) deployments need.

> Bike shed colors do not matter, bike shed colors for flying bike to
> bike communication is an interesting topic,

I agree with you that communicating bicycles may sound a far-fetched
scenario to some, but I also agree with hundreds of people working
precisely on the topic of communicating bicycles.  It saves lives.

The fact that you discard that as some 'flying' objects, presumably
assuming they are only on the drawing board, is not very kind.  Please
stop that.

Please do not be ignorant with topics that are important to others.

Moreover, I invite you to come and see the next demo events.

> but I suggest you avoid calling the current bike shed a failure and
> keeping its deployment reality a dirty secret.

I do not understand what you mean, but I want to let you know that I did 
work on connecting a Parking (including bike shed) to the IPv6 Internet.

I dont understand what you mean by 'keeping its deployment reality a 
dirty secret'.  The deployments I work often get publicized in public 
media and events.

> We tried that with nat44, it did not turn out well.

We agree on NAT is evil, but I dont understand: do you threaten with it?
I dont understand that here.

If we discuss threats, here is my reply:

It's now the 64share argument killing DHCP-PD at 3GPP that MAY make me
make a second deployment with NAT66.

Were 64share to be less all-encompassing in its claims, DHCPv6-PD may 
get in a stronger recommendation document to RFC, then to 3GPP and then 
to operators.

Alex

>
> CB
>
>
>
>
>> It is tricky if you want to further delegate from there,
>
> That 'tricky' scares me, really.
>
>> but works A-OK for its stated intended purpose.
>
> If its intended purposes are that 'deployments require 64 sharing',
> as RFC7849 puts it, please let me say I have strong doubts.
>
> If the intended purpose is "make one or two WiFi hotspots on a
> smartphone" - then say so everywhere.  Do not generalise, or falsely
> induce people into thinking 64share can be used to anything more than
> just that.
>
> Do not put this 64share into 3GPP specs.  Do not put this 64share
> into IETF documents having '3GPP' in their titles.
>
> It's as if I put my preferred 'Hello World' software in 3GPP specs.
> True, it runs on a smartphone, but what more could 3GPP care about
> it.
>
> 3GPP does much more about extendign networks at the edges than just
> one or two wifi hotspots on a smartphone.  64share does not scale to
>  that.
>
> But let me ask: what is the intended purpose of 64share from your
> point of view?
>
> Alex
>
> _______________________________________________ v6ops mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/v6ops
>